Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 79287 - Doesn't configure multiple language setups properly with new xkb model
Summary: Doesn't configure multiple language setups properly with new xkb model
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-keyboard
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact: David Lawrence
: 80141 (view as bug list)
Depends On:
Blocks: 79579
TreeView+ depends on / blocked
Reported: 2002-12-09 16:39 UTC by Leonid Kanter
Modified: 2008-01-17 17:49 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-05-25 14:31:14 UTC

Attachments (Terms of Use)

Description Leonid Kanter 2002-12-09 16:39:34 UTC
Description of Problem: 
If you install beta2 and seect Russian keyboard during installation, russian layout 
(alternative group!) is active by default and temporary group switch AltGr do not 
work. As a result, unable to enter "root" in gdm login window and so on. In all 
previous versions of Red Hat Linux keyboard was configured to us-ascii input by 
default, and cyrillic input with AltGr pressed. Now cyrillic by default, us-ascii input 
is not available at all! 
Version-Release number of selected component (if applicable): 
How Reproducible: 
Steps to Reproduce: 
1. start beta2 instalation 
2. select Russian keyboard 
Actual Results: 
you'll be unable to enter us-ascii characters on "add new user" screen and gdm 
login screen, it's even impossible to log in as root 
Expected Results: 
us-ascii input must be active by default, with possibility to select alternative group 
Additional Information: 
I tried to add line: 
option"XkbOptions" "grp:ctrl_shift_toggle,grpled:scroll" 
which always worked for me before. It doesn't work too: after X server restart I found 
that cyrillic input is still active by default and I'm still unable to switch group. And 
grpled doesn't show alternative group.

Comment 1 Jens Petersen 2002-12-12 07:27:24 UTC
Sounds to me like a redhat-config-keyboard but I could be wrong.

Comment 2 Eugene Kanter 2002-12-14 19:35:52 UTC
All of this does not happen under KDE, it is 100% GNOME issue or changes in X
broke GNOME but did not affect KDE at all. Seems like it might be related
somehow to bug 75109 - problems with X input method.

Comment 3 Eugene Kanter 2002-12-14 19:37:31 UTC
Another test case:
In XF86Config keyboard map set to "us".
Start GNOME, gnome-terminal, type "setxkbmap ru"
type something. no changes, still English. start gedit. type. Russian
letters. type "setxkbmap us" in terminal type in gedit - no changes,
still Russian. Start evolution or any other GTK-1.2. changes from
English to Russian follow setxkbmap.

Default keyboard in "ru" map is English so "setxkbmap ru" alone should
not change anything at all. Under KDE setxkbmap behaves properly.

Comment 4 Mike A. Harris 2002-12-19 11:29:50 UTC
Then it can't really be an xkb/XFree86 issue IMHO if it works in KDE and
not in GNOME.  It would IMHO be a GNOME issue.

Comment 5 Mike A. Harris 2002-12-19 11:31:13 UTC
Any comments Owen?

Comment 6 Leonid Kanter 2002-12-19 12:03:07 UTC
Actually I see two different bugs here. You can try following: open both konsole
and gnome-terminal and enter command "setxkbmap ru -option
grp:ctrl_shift_toggle" in any terminal. Than try to type something in
gnome-terminal ad in konsole. 

in gnome-terminal you'll see ascii characters, and it is gnome bug. it must be
filed as a separate bug.

in konsole you'll see cyrillic characters (if right iso10646-1 font is used),
but grp:ctrl_shift doesn't work as group swich and it's really XFree bug.
Pressing ctrl-shift must restore ascii input in console, but it doesn't work. to
restore ascii input, you must go to gnome-terminal and type "setxkbmap us" there!

grp_led:scroll option which I always had as a group indicator also doesn't work.

Comment 7 Leonid Kanter 2002-12-19 12:11:01 UTC
I've just tried following:

mv /usr/X11R6/lib/X11/xkb /usr/X11R6/lib/X11/xkb.orig
scp -r /usr/X11R6/lib/X11

and repeat experiment. In this case I got the same behavior in both konsole and
gnome-terminal. I also tried to install latest gnome-2.1.X programs on rh 8.0
box (including rawhide gnome-terminal 2.1.3) and there are no any problems with
cyrillic input and group switching in XFree 4.2, so I don's see any reasons to
disturb Oven Taylor. The problem is in XFree.

Comment 8 Leonid Kanter 2002-12-19 14:46:21 UTC
There is also no problem with cyrillic keyboard input if I use beta2 gdm login from rh 
7.3 or 8.0 X-servers. So all clients and xlib are OK and problem is in server 

Comment 9 Owen Taylor 2002-12-19 16:58:39 UTC
I have a lot of trouble imagining how this could be different in GNOME
and KDE. Using the XKB mode map, key symbols corresponding to Cyrillic
or Roman characters are sent to the app, and the app simply needs to 
convert them into text. There is very, very little magic that the 
app needs to do.

If GTK+ doesn't follow setxkbmap, that may be a GTK+ bug, and should 
be filed separately. (Though I can't reproduce that in quick testing.)
But, the normal case is that the keyboard map is simply set on login.

Comment 10 Eugene Kanter 2002-12-19 18:02:15 UTC
Oven, did you see bug 75109? The input method behaviour is very different in

Comment 11 Owen Taylor 2002-12-19 18:17:51 UTC
Bug 75109 is GTK2 working, GTK+-1.2/Qt not working, which is easy
to understand:

 - GTK2 is handling russian input in a really simple foolproof way
 - GTK+-1.2/Qt go through Xlib i18n code.

I guess I should have said "It's really hard for me to understand
how this could be working in KDE and not working in GNOME :-)".

Comment 12 Mike A. Harris 2002-12-20 11:38:01 UTC
>cyrillic input and group switching in XFree 4.2, so I don's see any
>reasons to disturb Oven Taylor. The problem is in XFree.

I am not "disturbing" Owen Taylor, and I take offense at you suggesting
that my asking Owen for his opinion on this issue is a bother to him. He
is capable of deciding that.  Developers here work together as a team on

At any rate, from what I can see above, I do not consider this an XFree86
bug.  If it is indeed an XFree86 bug, it goes beyond my knowledge of XFree86
keyboard mapping tables, and would not be a Red Hat specific problem, but
would affect XFree86 across the board.  It should be reported upstream
directly so that an xkb expert can give their opinion on the matter.

You can file a bug report at, or you can discuss the
issue in the open forum.  I am defering this issue to upstream to handle, so that it gets the proper attention
that it deserves by those greatly familiar with the mapping tables, and
the major changes that have occured recently in them.  Once reported there,
if it is considered a bug, most likely it will be fixed quickly, as all
bugs reported against xkb upstream as of late have been fixed within a

Setting to DEFERRED status pending upstream fix.

Comment 13 Aleksey Nogin 2003-01-06 07:31:34 UTC
beta3/KDE status:

1) If I do
setxkbmap en_US+ru -option grp:ctrl_shift_toggle -option grp_led:scroll
then everything works (who-ho!)

2) If I do
setxkbmap ru -option grp:ctrl_shift_toggle -option grp_led:scroll
then I am "stuck" on Cyrillics with no way to get back ta ASCII (w/o another
setxkbmap call)

3) redhat-config-xfree86 creates:
Option      "XkbLayout" "ru"
which acts like (2) - e.g. no way to even log in.

I do not know what of the above is the bug. But, obviously, either (2) is an
XFree bug, or (3) is an redhat-config-xfree86 bug (or, more specifically,
redhat-config-xfree86 not being up-to-speed with the latest developments in
XFree xkb setup) since together they make the system unusable.

Comment 14 Mike A. Harris 2003-01-22 23:32:02 UTC
You can file a bug report at, or you can discuss the
issue in the open forum.  I am defering this issue to upstream to handle, so that it gets the proper attention
that it deserves by those greatly familiar with the mapping tables, and
the major changes that have occured recently in them.  Once reported there,
if it is considered a bug, most likely it will be fixed quickly, as all
bugs reported against xkb upstream as of late have been fixed within a

Comment 15 Leonid Kanter 2003-01-23 10:56:12 UTC
This is not a bug, but feature of new xkb model. This feature allows to use more
than two keyboard layouts like this:

Option      "XkbLayout" "us,ru,ua,de"

But if only "ru" is listed in config, it's impossible to switch to "us",
impossible to add new user in firstboot, impossible to login as root and so on.
I already discussed this directly with Xfree developer who did this change (Ivan
Pascal). Can I open this bug for public access to let him take part in this

Comment 16 Mike A. Harris 2003-01-23 11:51:18 UTC
No, this bug report contains private data.  Please open a new bug report
that is against phoebe beta instead, then fill in the details there, leaving
out NDA and private info, and we'll set this one depending on the other
one.  Further discussion can then take place publically.

For the record, now that I've looked into the matter a bit deeper, I believe
you are correct, and this is indeed a change that is required in our
config tool.  I'm bumping the priority of this as well, as it is rather
important to European, Asian, and other multilingual groups of people. I'm
also adding our i18n team to the CC.

Comment 17 Brent Fox 2003-01-23 19:51:05 UTC
Please see bug #82440 for the redhat-config-keyboard that should fix this
problem.  It does not load mulitple keymaps like "us,ru,ua,de", but it doesn
load a us keymap in addition to the non-latin keymap.  It should also configure
the XkbOption "grp:ctrl_shift_toggle" to allow you to switch between the modes.

Jeremy says that the installer picks up these changes as well, so you should be
able to pick a Russian keyboard in the installer and still be able to toggle to
a us keymap.  QA, please verify with the latest tree.

Comment 18 Leonid Kanter 2003-01-23 20:51:19 UTC
*** Bug 80141 has been marked as a duplicate of this bug. ***

Comment 19 Milan Kerslager 2003-01-23 21:26:22 UTC
Beta 4 is still the same like Beta 3. So changing version.

Comment 20 Mike A. Harris 2003-01-24 06:03:07 UTC
*** Bug 80141 has been marked as a duplicate of this bug. ***

Comment 21 Leonid Kanter 2003-02-07 14:29:34 UTC
I've just installed GinGin-re0204.0, it's fixed only partially. After
installation XF86Config has line Option "XkbLayout" "ru,us", but switch was not
configured and I was still unable to add user or type "root" to login as root. I
had to kill firstboot (ctrl-alt-backspace), edit XF86Config (add line "Option
"XkbOptions" "grp:ctrl_shift_toggle" and reboot box to enter ascii data in

Comment 22 Leonid Kanter 2003-02-07 14:39:56 UTC
redhat-config-keyboard is OK, i tested it: if I remove line "Option
"XkbOptions" "grp:ctrl_shift_toggle", redhat-config-keyboard will add it if
Russian keyboard is selected. So anaconda must be fixed in the same way.

Comment 23 Eugene Kanter 2003-02-07 15:50:32 UTC
The issue is still present in pre-beta5. There is XkbLayout "ru,us" (correct)
but no "XkbOptions" "grp:ctrl_shift_toggle" and no indicator LED configured. I
got up to enter root password screen and got stuck there.....
Back to anaconda.

Comment 24 Brent Fox 2003-02-07 19:46:29 UTC
I think the anaconda problem may have been fixed with the change I made
yesterday to in rhpl:

Update of /usr/local/CVS/rhpl/src
In directory

Modified Files: 
Log Message:
make sure kbd options get set if they exist

RCS file: /usr/local/CVS/rhpl/src/,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- 22 Jan 2003 14:37:54 -0000      1.10
+++ 6 Feb 2003 20:01:59 -0000       1.11
@@ -85,7 +85,7 @@
         elif item == "variant":
             return kb[3]
         elif item == "options":
-            return ""
+            return kb[4]
         elif item == "name":
             return kb[0]
         elif item == "keytable":

This should cause the "XkbOptions" "grp:ctrl_shift_toggle" to get written out,
but I'm not sure about the LED indicator.  What do I need to do there?

Comment 25 Eugene Kanter 2003-02-07 20:49:19 UTC
You need to add "grp_led:scroll" to the "XkbOption". You can probably test
adding one more Option "XkbOption" line for clearness if X supports it.

The following worked for me in XFree 4.2

Option      "XkbOptions"        "grp:ctrl_shift_toggle,grp_led:scroll"

Would also be nice if switch "ctrl_shift_toggle" was configurable. There are
several variants available.

Comment 26 Leonid Kanter 2003-02-07 21:02:48 UTC
"XkbOptions" "grp:ctrl_shift_toggle,grp_led:scroll" works in both XFree 4.2 and

All possible switches for grp: and leds for grp_led: are listed in

Comment 27 Brent Fox 2003-02-07 23:34:47 UTC
Ok, I've added the grp_led:scroll for all the Russian keyboard models.  The
Russian part of the table now looks like:

'ru' : [_('Russian'), 'ru,us', 'pc105', '', 'grp:ctrl_shift_toggle,grp_led:scroll'],

'ru-cp1251': [_('Russian (cp1251)'), 'ru,us', 'pc105', '',

'ru-ms': [_('Russian (Microsoft)'), 'ru,us', 'pc105', '',

 'ru1' : [_('Russian (ru1)'), 'ru,us', 'pc105', '',

 'ru2' : [_('Russian (ru2)'), 'ru,us', 'pc105', '',

 'ru_win' : [_('Russian (win)'), 'ru,us', 'pc105', '',

This should be fixed in rhpl-0.90-1.  I think that should be all that is needed
to resolve this problem but if any other changes are needed, please reopen this
bug report.

Comment 28 Eugene Kanter 2003-02-09 19:11:47 UTC
Above changes for keyboard switcher and led indicator should be activated not 
only for Russian but for all other languages which require 'lg,us' (where lg is 
language code) listed in XF86Config file. 

Comment 29 Aleksey Nogin 2003-02-09 21:17:49 UTC
BTW, why "lg,us" and not "us.lg"?

Comment 30 Milan Kerslager 2003-02-09 21:26:58 UTC
Because Anaconda does 'lg,us' (ie: national keymap is active as default when is
picked up in keyboard config screen). is right.

Comment 31 Milan Kerslager 2003-02-11 18:49:32 UTC
In the Czech language the line:

Option      "XkbOptions"        "grp:ctrl_shift_toggle,grp_led:scroll"

works ok (pre-Beta5). But the major default configs has grp:shift_toggle,
because our old keymaps had this as default (hard-encoded). So if I am able to
vote, change toggle to use both shifts in Anaconda as default please for Czech
(cs) language.

Comment 32 Milan Kerslager 2003-02-11 19:05:13 UTC
ctrl_shift_toggle is really bad choice as SHIFT+CTRL+[cv] are for cutting and
pasting text in Gnome terminal. If you would like to not break this, do not use
this as default for switching the keymaps please.

Comment 33 Brent Fox 2003-02-11 19:16:44 UTC
Ok.  Does everyone agree that using both Shift keys simultaneously is acceptable
for toggling (grp:shift_toggle)?

Comment 34 Eido Inoue 2003-02-11 20:17:45 UTC
actually, gnome-terminal should use something like ctrl+alt+[cv]. ctrl-shift-c
is needed for ISO 140755 unicode hex input.

Comment 35 Eido Inoue 2003-02-11 20:18:12 UTC
comment 34: make that ISO 14755

Comment 36 Eugene Kanter 2003-02-11 20:49:34 UTC
ctrl+shift is frequently used in emacs. Very good point. Please use

Comment 37 Leonid Kanter 2003-02-11 20:56:01 UTC
I agree that ctrl_shift_toggle can brake some things and shift_toggle is the
most safe combination.

Comment 38 Brent Fox 2003-02-11 21:31:07 UTC
Ok, I've converted all toggles in to grp:shift_toggle.  I
hope that this resolves this bug report.  Please test with rhpl-0.91-1.

Comment 39 Eugene Kanter 2003-02-11 23:44:37 UTC
The ideal solution would be to provide (on the keyboard selection screen) a pull
down menu.

Comment 40 Brent Fox 2003-02-11 23:55:36 UTC
I disagree.  I think that the solution is to pick a good default and stick with
it instead of just making everything configurable.  Many Linux config tools have
made that mistake in the past and pretty soon you have a config tool that tries
to do too much and winds up making the common case hard.

If people really, really want to change the toggle, they are free to edit the
XF86Config file by hand.

Comment 41 Milan Kerslager 2003-02-12 00:39:17 UTC
I partially disagree. Anaconda is not the right place for making the choice
(when there is a good non-critical default). But the user-config tool should be
able to do this. Switching the keymaps are heavily used in non-US environment as
there is usually a problem to write programs with a national keymap and there is
a problem to write national text with US keymap too.

So if you feel that RH should hit desktop you should make sure the users have no
problem to use it without a pain (imagine the problem when you should work and
you do not want to hack own new desktop).

At least there is a possibility to pick up different toggle in Windows so you
can not satisfy all migrating users. In our language there is a default
Alt+Shift (in Windows, but there is more variants the user can easily use) so
Shift-Shift will probably not be what everybody wants to use.

Wish anybody fill up RFE for redhat-config-keyboard for next release.

Comment 42 Milan Kerslager 2003-03-06 18:53:52 UTC
I did fresh Beta5 install, Czech language, Czech keymap. Anaconda writes:

Option      "XkbLayout" "cz_qwerty"

Where is us keymap? This is impossible to write email address and other normal
chars from US keyboard in firstboot and in X then too. I supposed this was fixed
but not yet! We really need:

Option      "XkbLayout" "us,cz_qwerty"

Comment 43 Eugene Kanter 2003-03-06 19:31:03 UTC
Since no developer responded on a comment there is a very
high probability that it was not implemented for languages other then Russian.

Comment 44 Mike A. Harris 2003-03-06 21:53:43 UTC
It might be better to file new bug reports in new bugzilla entries, rather
than filling up one that is already very long.  It makes it easier to know
what issues are still present without having to read a very long bug report.

Just a suggestion.

Comment 45 Milan Kerslager 2003-03-06 22:15:34 UTC
Ok. New short bug filled. See bug #85751. Mark this as duplicate to track it.

*** This bug has been marked as a duplicate of 85751 ***

Comment 46 Mike A. Harris 2003-03-06 22:49:19 UTC
Sorry..  I wasn't implying that your comment was a duplicate.
This bug was in MODIFIED state, which means developers are waiting for
the original bug reporter to say "it is fixed now, thanks" and close
it as RAWHIDE, or to reopen it and say "it is not fixed".

Comment 47 Mike A. Harris 2003-03-06 22:49:48 UTC
argh..  bugilla goofed me there.

Comment 48 Mike A. Harris 2003-03-06 22:51:01 UTC
Setting back to MODIFIED pending original reporter's feedback on testing
existing packages for the problem reported in the original comment.

Comment 49 Brent Fox 2003-05-25 14:31:14 UTC
There is a stack of 64 bugs that have been in Modified state for a long period
of time.  I am closing these as Rawhide now.  If you find that the issue is not
fixed, please reopen this report.

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