Bug 125130 - Polish keymap is not Unicode/UTF-8 aware
Polish keymap is not Unicode/UTF-8 aware
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kbd (Show other bugs)
2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-02 18:17 EDT by Marcin Garski
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-18 12:07:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for utf8-ization pl2 keymap (2.86 KB, patch)
2004-06-02 18:19 EDT, Marcin Garski
no flags Details | Diff

  None (edit)
Description Marcin Garski 2004-06-02 18:17:27 EDT
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:
Comment 1 Marcin Garski 2004-06-02 18:19:49 EDT
Created attachment 100807 [details]
Patch for utf8-ization pl2 keymap
Comment 2 Dawid Gajownik 2004-09-01 15:35:27 EDT
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?
Comment 3 Marcin Garski 2004-11-11 15:06:14 EST
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
Comment 4 Dawid Gajownik 2004-11-11 17:05:40 EST
> 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...
Comment 5 Dawid Gajownik 2004-11-12 03:49:23 EST
Silly me... There should be "use" (not "uses") and "to" (not "do") ;-)
Comment 6 Dawid Gajownik 2004-12-19 04:32:10 EST
Well, rc.sysinit from new initscripts package from Rawhide uses
loadkeys with option "-u", so this bug report can be closed :D
Comment 7 Miloslav Trmač 2005-02-18 12:07:47 EST
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.

Note You need to log in before you can comment on or make changes to this bug.