1 |
Hi Nikos, |
2 |
|
3 |
> On my /etc/rc.conf, there's this: |
4 |
> |
5 |
> # Set unicode to YES to turn on unicode support for keyboards |
6 |
> # and screens. |
7 |
> unicode="YES" |
8 |
|
9 |
It's set to "no" on my machine (I already posted this; this was the |
10 |
first thing outside the kernel that I considered, I think). (I haven't |
11 |
yet posted that I use sys-apps/baselayout-1.12.11.1, though - not sure |
12 |
how this relates to the OpenRC you are mentioning.) |
13 |
|
14 |
> So I suppose maybe simpley changing this to "NO" will do the job. |
15 |
|
16 |
Curiously, it does not, even though it seems supposed to do it, using |
17 |
the very mechanisms we already discussed (kbd_mode and console escape |
18 |
sequences). It's a little strange: |
19 |
|
20 |
> Try "grep -ri unicode /etc" and see what you find. |
21 |
|
22 |
Doing this, I found out that /etc/runlevels/boot/keymaps and |
23 |
/etc/init.d/keymaps do use this variable, but do so for setting the |
24 |
keyboard encoding only if it's set to "yes". In other words, if the |
25 |
kernel starts up with 8-bit encoding for the console, these scripts (I |
26 |
don't know which one, perhaps both - they seem to do the same thing in |
27 |
this respect) will switch to unicode for the keyboard, but not the |
28 |
other way round (i.e. the if statement "if [[${UNICODE} == 'yes']]" |
29 |
has no else part, so if $UNICODE has a different value, such as 'no', |
30 |
it is simply ignored, and nothing happens). For the terminal encoding, |
31 |
however, the scripts seem to act both ways (the if statement does have |
32 |
an else part). Strange, to me (or am I overlooking something?). |
33 |
|
34 |
(I'm not sure, BTW, whether the double '=' is a gentoo peculiarity, |
35 |
nor whether this kind of string comparison is case-insensitive. But in |
36 |
any case, the scripts only test for "yes", in lower case, so anything |
37 |
else should effectively mean "no".) |
38 |
|
39 |
Best regards, |
40 |
|
41 |
Florian |