Re: [gentoo-user] Re: Kernel update messed up console encoding

["Florian v. Savigny" <lorian@fsavigny.de>]

Hi Nikos,

  > On my /etc/rc.conf, there's this:
  > 
  >    # Set unicode to YES to turn on unicode support for keyboards
  >    # and screens.
  >    unicode="YES"

It's set to "no" on my machine (I already posted this; this was the
first thing outside the kernel that I considered, I think). (I haven't
yet posted that I use sys-apps/baselayout-1.12.11.1, though - not sure
how this relates to the OpenRC you are mentioning.)

  > So I suppose maybe simpley changing this to "NO" will do the job.

Curiously, it does not, even though it seems supposed to do it, using
the very mechanisms we already discussed (kbd_mode and console escape
sequences). It's a little strange:

  > Try "grep -ri unicode /etc" and see what you find.

Doing this, I found out that /etc/runlevels/boot/keymaps and
/etc/init.d/keymaps do use this variable, but do so for setting the
keyboard encoding only if it's set to "yes". In other words, if the
kernel starts up with 8-bit encoding for the console, these scripts (I
don't know which one, perhaps both - they seem to do the same thing in
this respect) will switch to unicode for the keyboard, but not the
other way round (i.e. the if statement "if [[${UNICODE} == 'yes']]"
has no else part, so if $UNICODE has a different value, such as 'no',
it is simply ignored, and nothing happens). For the terminal encoding,
however, the scripts seem to act both ways (the if statement does have
an else part). Strange, to me (or am I overlooking something?).

(I'm not sure, BTW, whether the double '=' is a gentoo peculiarity,
nor whether this kind of string comparison is case-insensitive. But in
any case, the scripts only test for "yes", in lower case, so anything
else should effectively mean "no".)

Best regards,

Florian