At startup there should be the keymaping assigned as specified in rc.conf. But there seems to be a parsing error I can't explain since the keymap file is correct to me. I have reemerged kbd too but it brought nothing. Here is what's on screen at startup: * Loading key mappings ... unknown keysym 'Meta_acute' /usr/share/keymaps/i386/qwertz/de-latin1.map.gz:34: parse error syntax error in map file key bindings not changed * Error loading key mappings [!!]
Created attachment 19858 [details] rc.conf with error in key mapping
vim /usr/share/keymaps/i386/qwertz/de-latin1.map.gz and comment the offending line # alt keycode 13 = Meta_acute vim is smart enough to unzip/edit/rezip file Meta_acute does not look like it should even exist.
keycode 13 = dead_acute dead_grave alt keycode 13 = Meta_acute shift alt keycode 13 = Meta_grave This is from the SuSE de-latin1.map.gz so there should be no problem with that Meta_acute in that file. Both kbds are version 1.06. Is that name "Meta_acute" anyhow related to the kernel maybe? Since I use kernel 2.6-test8. But I don't know since when this kernel exists.
I meant "problem" when I said "kernel". So I don't really know since when this problem exists. Sorry for beeing such a complete retard.
My kernel is 2.4.20 There is no Meta_acute in /usr/src/linux/drivers/char/defkeymap.map Same applies to 2.4.19, 2.4.22, 2.5.75 and 2.6.0-test6 It might be/have been a Suse hack or it has been removed. I can't easily find any reference to a meta_acute (google gives me only 4 links) and I don't feel like downloading a suse kernel. Replace meta-acute by whatever you expect alt-4 (or what is below the 4) to do on your keyboard. Sorry I can't help any further.
dumpkeys -l|grep Meta_acute on SuSE gives no answer so Meta_acute is indeed a false keysym. So there are two questions left. 1.) Why was it working (till what ever)? 2.) Why does it ship with mappings with unknown keysyms! 3.) Does it work at your side with my settings (watch attached rc.conf)? 4.) Was I really saying something about "two questions left"?
FYI, this is my rc.conf (partly): KEYMAP="us-happyhacking" EXTENDED_KEYMAP= SET_WINDOWKEYS="yes" I noticed the same problem as you did with the "-u" in front of the keymap. When passed to loadkeys, it causes the error. When loadkeys is called without it, your keymap is accepted. As you most likely want the keep the -u, I suggest you comment out the offending line in your keymap. Answers in sequence 1.) Until "-u " was prepended to keymap name and/or processed by loadkeys ? 2.) Because it takes someone to notice and report. You did. 3.) works without "-u", not with it. 4.) Was there a fourth point ?
when commented out no errors appearing anymore but umlauts (
when commented out no errors appearing anymore but umlauts (üÜöÖäÄ) won't come correctly on the screen following warnings may depend on that issue: plus before udiaeresis ignored plus before Udiaeresis ignored plus before odiaeresis ignored plus before Odiaeresis ignored plus before adiaeresis ignored plus before Adiaeresis ignored So this doesn't seems to be a simple one, when I need UTF-8 support on console, too...
What about this patch: -- Index: init.d/keymaps =================================================================== RCS file: /home/cvsroot/gentoo-src/rc-scripts/init.d/keymaps,v retrieving revision 1.17 diff -u -r1.17 keymaps --- init.d/keymaps 16 Jul 2003 19:38:51 -0000 1.17 +++ init.d/keymaps 29 Oct 2003 19:54:41 -0000 @@ -34,6 +34,7 @@ if [ "$1" = "-u" ] then /usr/bin/kbd_mode -u + KEYMAP="${KEYMAP/-u}" fi # New kbd support ...
The patch seems to fix most issues but I'm not able to input a '@'-sign which is Alt-Gr+Q on my keyboard. I just hear a system beep if I try to... All other signs that need Alt-Gr are available it seems. So why @ not?
unicode_start $CONSOLEFONT should be started somewhere to after doing this shell support for unicode seems to function but this should be done after consolefont and keymap initscripts or before or in there I don't know really :o) So maybe package maintainers of that two should be informed and need to handle this since unicode support is quite important...
ok to summarize this: can anybody please explain what the correct way of enabling utf-8 in the console is?
You might want to read this thread on f.g.o http://forums.gentoo.org/viewtopic.php?t=221588 The author can't use the compose key to type utf8 chars. Displaying utf8 chars works but I haven't been able to type utf8 chars either. The unicode howto on tldp is not very helpful http://www.tldp.org/HOWTO/Unicode-HOWTO-2.html#ss2.1
Here are two new patches for /etc/init.d/keymaps and /etc/rc.conf to automatically exec unicode_start, azarah please include them ;)
Created attachment 40106 [details, diff] rc.conf.unicode.patch
Created attachment 40107 [details, diff] keymaps.unicode.patch
*** Bug 55343 has been marked as a duplicate of this bug. ***
Created attachment 41443 [details, diff] utf8-console.patch could you guys review this and see if this works for you both ? you guys had slightly different patches ... for one thing, one of you echoed '\033%G' into the tty device while the other echoed '\033%K' ... which is correct ?
'\033%G' should be correct as /usr/bin/unicode_start also uses that... unicode_start belongs to kbd in the latest patch you echo both values to the ttys and there's a syntax error in keymap... a missing "do" in the for loop
Created attachment 41903 [details, diff] utf8-console2.patch this incorporates your suggestions/fixes ... please try this out :)
ebegin "Setting terminal encoding to ${termencoding}" has to be ebegin "Setting terminal encoding to ${termmsg}" other than that it seems ok... i'll try later
i'm happy with this last version (with your added termmsg fix), so if you guys say it works for you, i'll commit it
Created attachment 42107 [details, diff] Enable console unicode support in my french setup. I did small modifications on the original utf8-console2.patch. As far as my french gentoo setup is concerned, it does work for me (the original did not).
ok, thanks for the fixes, added all of the latest work to cvs look for it in 1.11.3+
