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
Florian v. Savigny wrote:
[...]
I think I'll continue on a kernel list to figure out what kernel
2.6.27 does differently from 2.6.17, and why (and whether that
behaviour cannot be changed with a compile-time option). I think that
part is really not a gentoo-specific question. But I'll report here
Hi Nikos,
> Maybe the commands "unicode_start" and "unicode_stop" might help.
Bull's eye! "unicode_stop" reverses the behavior completely to what
the old kernel did.
I looked inside; both are actually shell scripts; unicode_stop is very
simple:
kbd_mode -a
if test -t ; then
ech
Florian v. Savigny wrote:
[...]
But still, I am wondering how to get the new kernel to behave as I
want out of the box. My best guess is now that this console behaviour
has become the default at some point between kernels 2.6.17 and
2.6.27, and that you now have to switch it off explicitely. But
Hi Nikos,
> > $LANG and $LC_ALL are not set (i.e. locale simply shows
> > "LANG=" and "LC_ALL=" with no values). All other LC_... variables are
> > set to "POSIX".
>
> I don't think that will work.
Interestingly, I just discovered the locales are different for one
user (who has "de_DE
Florian v. Savigny wrote:
> locale
> should shown it to you
Thanks. $LANG and $LC_ALL are not set (i.e. locale simply shows
"LANG=" and "LC_ALL=" with no values). All other LC_... variables are
set to "POSIX".
I don't think that will work. Here, locale says:
LANG=en_US.UTF-8
LC_CTYP
6 matches
Mail list logo
