Red Hat Bugzilla – Bug 139500
KEYTABLE set wrong
Last modified: 2007-11-30 17:10:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Description of problem:
As requested by Daniel Veillard in bug 100686 comment 36.
How is rhgb supposed to understand that "slovene" means "si" ?
That's why it broke, for a french configured keyboard you get
something based on the ISO country name like "fr" or "fr_FR".
I think the generation of the KEYTABLE value is wrong, potentially
an anaconda bug...
Option "XkbModel" "pc105"
Option "XkbLayout" "si"
Version-Release number of selected component (if applicable):
KEYTABLE is looked up using keyboard_models in rhpl:
>>> import rhpl.keyboard_models
>>> k = rhpl.keyboard_models.KeyboardModels()
['Slovenian', 'si', 'pc105', '', '']
For some languages the key is the X keymap but that's not guaranteed.
I'd say that rhgb's assumption is incorrect (but happens to work for
fr say). I'll have a think over possible solutions
Daniel I don't think you can assume that KEYTABLE= the x keymap as
it's the lookup key for both console and x11 keymap, plus for some
locales we set up 2 X keymaps.
Would me adding an X11KEYMAP in /etc/sysconfig/keyboard be good for
you? Do you only want both keymaps for things such as indic languages
which we list as eg: us,ben(probhat)
Paul, yes that would be excellent for me !
Unfortunately the method relying on xf86openConfigFile()
and searching in the specific X11 construct used to specify
the keyboard is really hard to maintain and apparently doesn't
seems to work right now.
So falling back to getting the informations directly from
the source would be way more reliable.
What I really need is the setxkbmap layout argument string,
if there is two I have no idea which one should be used (assuming
both can't be configured at the same time).
Closing due to inactivity. If this issue still occurs with current releases,
please reopen and set the release in which you've encountered the problem.