From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: Under console (in text mode, not under console in X Window) i can't get polish letters (default FC2 installation, polish locale, keymap set to pl by anaconda), except o with acute (maybe O with acute, i haven't checked capital letters). If i type Ctrl+c, c with acute should appear on console but instead strange character appear. If i switch to changed (example below) pl2 keymap, (which is almost the same as pl, but in pl both Alt keys give pl letters instead of pl2 where only right Alt give pl letters) eg: keycode 46 = c AltGr keycode 46 = +cacute AltGr Shift keycode 46 = +Cacute is replaced by: keycode 46 = c AltGr keycode 46 = U+0107 AltGr Shift keycode 46 = U+0106 (+cacute is replaced by Unicode code of letter) i can get polish letters (i've attached patch that replace all polish letters with it Unicode code). BTW default polish keymap in FC2 is pl, but it should be pl2 - that's next bug. Version-Release number of selected component (if applicable): kbd-1.12-1 How reproducible: Always Steps to Reproduce: 1. Set keymap to pl2 2. Log into account 3. Try to write some polish letters on console Additional info:
Created attachment 100807 [details] Patch for utf8-ization pl2 keymap
Hi! I searched through Bugzilla and noticed that "loadkeys -u pl" resolves the problem without patching (what a pity, that -u option is not even mentioned in manpage :( It should be updated). I looked at the attachment and I have one question - Marcin, are you sure about UTF-8 charset? I changed the charset from iso-8859-2 to UTF-8 in pl.map.gz file and have something like this: [y4kk0@X y4kk0]$ loadkeys -u pl Loading /lib/kbd/keymaps/i386/qwerty/pl.map.gz unknown charset UTF-8 - ignoring charset request [y4kk0@X y4kk0]$ loadkeys pl Loading /lib/kbd/keymaps/i386/qwerty/pl.map.gz unknown charset utf8 - ignoring charset request assuming iso-8859-2 eogonek assuming iso-8859-2 eogonek assuming iso-8859-2 Eogonek assuming iso-8859-2 Eogonek assuming iso-8859-2 aogonek assuming iso-8859-2 aogonek assuming iso-8859-2 Aogonek assuming iso-8859-2 Aogonek assuming iso-8859-2 sacute assuming iso-8859-2 sacute assuming iso-8859-2 Sacute assuming iso-8859-2 Sacute assuming iso-8859-2 lstroke assuming iso-8859-2 lstroke assuming iso-8859-2 Lstroke assuming iso-8859-2 Lstroke assuming iso-8859-2 zabovedot assuming iso-8859-2 zabovedot assuming iso-8859-2 Zabovedot assuming iso-8859-2 Zabovedot assuming iso-8859-2 zacute assuming iso-8859-2 zacute assuming iso-8859-2 Zacute assuming iso-8859-2 Zacute assuming iso-8859-2 cacute assuming iso-8859-2 cacute assuming iso-8859-2 Cacute assuming iso-8859-2 Cacute assuming iso-8859-2 nacute assuming iso-8859-2 nacute assuming iso-8859-2 Nacute assuming iso-8859-2 Nacute [y4kk0@X y4kk0]$ loadkeys pl2-utf8 Loading /lib/kbd/keymaps/i386/qwerty/pl2-utf8.map.gz unknown charset UTF-8 - ignoring charset request The only problem is that I cannot get Aogonek, Oacute, etc. stuff when CapsLock is enabled - I need to press SHIFT, because withou it I have aogonek, oacute, etc. (like in this comment â https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81760#c7 ). I wonder if -u option could be set on by default in /etc/rc.d/rc.sysinit file... Will it have some bad influence on other keymaps? Oh, I almost forgot ;) pl2.map does not treat Alt key as AltGR (which is correct). Are there any other differences?
1. On (http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Unicode-HOWTO.html#ss2.1) there is a phrase: "If your keyboard or, more precisely, your normal keymap has non-ASCII letter keys (like the German Umlaute) which you would like to be CapsLockable, you need to apply the kernel patch linux-2.2.9-keyboard.diff or linux-2.3.12-keyboard.diff." I don't know is this still up-to-date for 2.6 kernels, but can be? 2. You are right, there shouldn't be "charset "UTF-8"" in my pl2.map (it could be commented). 3. In rc.sysinit "loadkeys" should be run with "-u", but AFAIR only if others stuff is also switched to UTF. 4. I don't know are there any other differences betwen pl & pl2 (I'm a newbie in how keymaps are created). 5. Could someone who deeply know keymaps could write wich entry is "more" correct in Unicode keymap? AltGr keycode 18 = +eogonek ,or AltGr keycode 18 = U+0119
> Could someone who deeply know keymaps could write wich entry is "more" correct in Unicode keymap? I'm not a kind of person you are looking for ;-) but I found in keymaps man page something like this: "keysyms can be given in decimal, octal, hexadecimal, unicode or symbolic notation. The numeric notations use the same format as with keynumber. Unicode notation is "U+" followed by four hexadecimal digits. [snip] It should be noted that using numeric notation for the keysyms is highly unportable as the key action numbers may vary from one kernel version to another and the use of numeric notations is thus strongly discouraged. They are intended to be used only when you know there is a supported keyboard action in your kernel for which your current version of loadkeys(1) has no symbolic name." It seems that +eogonek is better than U+0119 - the main question is whether keymaps man page is up-to-date. I skimmed through utf keymaps in /lib/kbd/keymaps/i386/qwerty and most of them (or maybe all) uses numeric notation. I'm confused :/ How about changing Version do development? I don't think that it will be ever fixed in FC2...
Silly me... There should be "use" (not "uses") and "to" (not "do") ;-)
Well, rc.sysinit from new initscripts package from Rawhide uses loadkeys with option "-u", so this bug report can be closed :D
Hello, +eogonek is better because it (in theory, at least) marks the key to respect Caps Lock state; but the kernel currently doesn't support Caps Lock for Unicode symbols - and neither does loadkeys, so the patches referenced above can't currently help. With (loadkeys -u) in rawhide initscripts, that's the best we can do with the current kernel intefaces.