upgrade to kernel 2.6 broke console font mapping? - Slackware

This is a discussion on upgrade to kernel 2.6 broke console font mapping? - Slackware ; Problem: all the accented characters in latin-1 are mapped to the same glyph, a reverse-video questionmark. Prior to the upgrade, they were displayed correctly. Examining the character codes, I can see that they are what I expect, i.e. different latin-1 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: upgrade to kernel 2.6 broke console font mapping?

  1. upgrade to kernel 2.6 broke console font mapping?

    Problem: all the accented characters in latin-1 are mapped to the same
    glyph, a reverse-video questionmark.
    Prior to the upgrade, they were displayed correctly.
    Examining the character codes, I can see that they are what I expect,
    i.e. different latin-1 accented characters.

    showconsolefont tells me that the correct glyphs are present on the
    video card - I put them there after each
    boot using setfont lat1-16.psfu.gz
    [that's off the top of my head; I'm not at my Linux box right now] -
    but are just not being called for.

    The box is a Dell Gx1p with 400Mhz PII and ATI 3D RagePro AGP video.
    I'm using Slackware 11.x (which
    originally had kernel 2.4), minimally upgraded to run kernel 2.6.24.5-
    smp from Slackware 12.1. Because
    this was a partial, piecemeal upgrade, I may have accidentally broken
    the console font setup in some
    obscure way, but I've read the kbd doc without finding out how to fix
    it. Almost everything else works fine.

    I have kbd-1.12 installed, which is current for Slackware 12.1, and it
    says that setfont automatically installs
    the font mappings packaged with psfu fonts, so there's nothing to be
    done there. That seems to leave the
    possibility that I'm somehow in the wrong console mode, but I don't
    know why this might come about, or
    how to check on it. The reset program doesn't fix it. My lilo.conf
    uses vga=normal, which doesn't add
    anything to the kernel command line, and it correctly boots in 80x25
    mode.

    Ideas and clues gratefully received ...

  2. Re: upgrade to kernel 2.6 broke console font mapping?

    On Sat, 6 Sep 2008 12:56:52 -0700 (PDT), jim wrote:

    >Problem: all the accented characters in latin-1 are mapped to the same
    >glyph, a reverse-video questionmark.
    >Prior to the upgrade, they were displayed correctly.

    ....
    >The box is a Dell Gx1p with 400Mhz PII and ATI 3D RagePro AGP video.
    >I'm using Slackware 11.x (which
    >originally had kernel 2.4), minimally upgraded to run kernel 2.6.24.5-
    >smp from Slackware 12.1. Because
    >this was a partial, piecemeal upgrade, I may have accidentally broken
    >the console font setup in some
    >obscure way, but I've read the kbd doc without finding out how to fix
    >it. Almost everything else works fine.


    A strange way to update the kernel, I suggest you compile a custom
    kernel for the box which correctly references slack-11 libraries...

    Grant.
    --
    Cats, no less liquid than their shadows, offer no angles to the wind.

  3. Re: upgrade to kernel 2.6 broke console font mapping?

    jim writes:

    > Problem: all the accented characters in latin-1 are mapped to the same
    > glyph, a reverse-video questionmark.
    > Prior to the upgrade, they were displayed correctly.
    > Examining the character codes, I can see that they are what I expect,
    > i.e. different latin-1 accented characters.


    In latest linux 2.6 kernel, console defaults to UTF-8.

    You can append this to your lilo boot command line to disable
    this:

    vt.default_utf8=0

    Hope this helps.

  4. Re: upgrade to kernel 2.6 broke console font mapping?

    Grant wrote:
    > A strange way to update the kernel, I suggest you compile a custom
    > kernel for the box which correctly references slack-11 libraries...


    Sorry, I was trying to be terse; I attempted a minimal upgrade to
    allow the use
    of kernel 2.6, but I tried to be careful, so I also upgraded glibc,
    the package utilities,
    the kernel modules, their utilities, lilo, udev, other stuff I don't
    remember, and also bash,
    zoneinfo, binutils and gcc.

    The console font breakage was the most obvious unexpected consequence,
    closely followed by cursor strangeness on leaving and returning to
    text mode.
    "Serious" functionality was preserved :-) :-)



  5. Re: upgrade to kernel 2.6 broke console font mapping?

    On Sep 7, 4:50*am, Xavier Maillard wrote:
    > In latest linux 2.6 kernel, console defaults to UTF-8.
    >
    > You can append this to your lilo boot command line to disable
    > this:
    >
    > vt.default_utf8=0
    >
    > Hope this helps.


    Thank you! This seems very promising; I'll try it when I get home.

  6. Re: upgrade to kernel 2.6 broke console font mapping?

    On Sep 7, 4:50*am, Xavier Maillard wrote:
    > jim writes:
    > > Problem: all the accented characters in latin-1 are mapped to the same
    > > glyph, a reverse-video questionmark.

    > In latest linux 2.6 kernel, console defaults to UTF-8.


    I discovered that I had the kbd_mode command, so I can now return the
    console to "ascii"
    mode one vt at a time; I also tried the loadunimap command and setfont
    -m with various
    fontmaps including "def.uni" and "trivial".

    None of this had any effect on the problem that the different accented
    characters are all
    rendered as the same glyph. Exactly which glyph it is depends on what
    console font I load:
    the video card native font gives a square blob, and the default,
    lat1-16 and iso8859-1 fonts
    give a blank and two slightly different reverse-video question marks.
    As mentioned before,
    showconsolefont confirms that the accented glyphs are available (in
    different locations in
    different fonts :-), but not used.

    The kbd package also comes with a demo script which is supposed to set
    UTF-8 mode, display
    selected code points and their glyphs, and then restore ascii mode.
    On my box, this demo
    exhibits the same problem: most of the displayed glyphs are the same,
    though their text
    descriptions indicate that they should be different.

    Anyone have any clues about where to look next?

+ Reply to Thread