Summary: | sys-apps/openrc: console font & keymaps should disable UTF-8 when UNICODE=no | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Thomas <tg42> |
Component: | OpenRC | Assignee: | OpenRC Team <openrc> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | jan_zdarek, please.no.spam.here, vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://bugzilla.kernel.org/show_bug.cgi?id=9319 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Thomas
2008-03-26 21:21:10 UTC
The kernel parameter vt.default_utf8=0 switches back to ASCII / ISO as default. As noted on the upstream bug, this is not a kernel issue. If you set a keymap then the unicode setting will always be respected regardless of baselayout version. However, some baselayouts did not set terminal encoding correct, and I can't remember when I fixed it. It's safe to say that openrc does it correctly. openrc-0.3 will be able to set encoding independently of keymaps to make things easier. (In reply to comment #3) > If you set a keymap then the unicode setting will always be respected This is only correct for the pre 2.6.24 default: If the keyboard is in ASCII mode, it is correctly switched to unicode. If, however, the keyboard is in unicode mode by default, it is not switched back. In 2.6.24-r3 i have not found any way to switch a console in unicode mode back to ASCII mode. It always expects output to be UTF-8, so if the keyboard is switched to ASCII and e. g. Umlauts are entered, they are not displayed correctly. This is probably a kernel bug. To change tty1 to ASCII printf "\033%s" "%@" >/dev/tty1 kbd_mode -a -C /dev/tty1 To change tty1 to UTF-8 printf "\033%s" "%G" >/dev/tty1 kbd_mode -u -C /dev/tty1 Change /dev/tty1 to the terminal you want to change. If that fails to work, then yes it's a kernel bug. (In reply to comment #5) > To change tty1 to ASCII > printf "\033%s" "%@" >/dev/tty1 > kbd_mode -a -C /dev/tty1 > ... > If that fails to work, then yes it's a kernel bug. Both of these work as expected, so no kernel bug here. $ echo 0 > /sys/module/vt/parameters/default_utf8 does not have an effect, however. Wasn't it supposed to do the same? (In reply to comment #6) > Both of these work as expected, so no kernel bug here. > > $ echo 0 > /sys/module/vt/parameters/default_utf8 > > does not have an effect, however. Wasn't it supposed to do the same? I would guess that only applies to newly created terminals, not existing ones. This is a change in default kernel behaviour. The solution is to make the vt settings at boot time. I suggest adding the following lines into /etc/init.d/bootmisc : if [ -f "/sys/module/vt/parameters/default_utf8" ]; then ebegin "Disabling terminal UTF-8 default setting \ (`/bin/cat /sys/module/vt/parameters/default_utf8`)" echo 0 > "/sys/module/vt/parameters/default_utf8" eend 0 else ewarn "Cannot disable terminal UTF-8 default setting \ (/sys/module/vt/parameters/default_utf8 missing)" fi No other change has to be made, I use the same settings (/etc/conf.d/consolefont) as before (kernel 2.6.23 r9). Tested on 2.6.27-gentoo-r8, ISO-8859-2, CONSOLEFONT="lat2-16". ASCII only defines bytes 0x00 to 0x7F, and they're the same as UTF-8. other encodings, like ISO-8859-1, define 0x80 - 0xFF differently from UTF-8, and that includes ä. LANG=de_DE does not declare an encoding. i'm guessing you're using ISO-8859-1 though as that is usually the default. Happy new Year! (Now this was a long period of silence... ;-) Yes, the default for de_DE is ISO-8859-1. I even run some machines with UNICODE=no still (and use the kernel parameter there). |