Bug 79287

Sounds to me like a redhat-config-keyboard but I could be wrong.

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.

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.

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.

Any comments Owen?

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.

I've just tried following:

mv /usr/X11R6/lib/X11/xkb /usr/X11R6/lib/X11/xkb.orig
scp -r my.rh8_0.box/usr/X11R6/lib/X11/xkb /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.

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 4.2.99.2 server 
only. 

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.

Oven, did you see bug 75109? The input method behaviour is very different in
GNOME and KDE.

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 :-)".

>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
issues.

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 xfree86, or you can discuss the
issue in the open xpert forum.  I am defering this issue to
XFree86.org 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
week.

Setting to DEFERRED status pending upstream fix.

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.

You can file a bug report at xfree86, or you can discuss the
issue in the open xpert forum.  I am defering this issue to
XFree86.org 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
week.

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
discussion?

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.

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.

*** Bug 80141 has been marked as a duplicate of this bug. ***

Beta 4 is still the same like Beta 3. So changing version.

*** Bug 80141 has been marked as a duplicate of this bug. ***

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
firstboot.

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.

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.

I think the anaconda problem may have been fixed with the change I made
yesterday to keyboard.py in rhpl:

Update of /usr/local/CVS/rhpl/src
In directory elvis.redhat.com:/tmp/cvs-serv25079

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

Index: keyboard.py
===================================================================
RCS file: /usr/local/CVS/rhpl/src/keyboard.py,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- keyboard.py 22 Jan 2003 14:37:54 -0000      1.10
+++ keyboard.py 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?

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.

"XkbOptions" "grp:ctrl_shift_toggle,grp_led:scroll" works in both XFree 4.2 and
4.3. 

All possible switches for grp: and leds for grp_led: are listed in
/usr/X11R6/lib/X11/xkb/rules/xfree86.lst

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', '',
'grp:ctrl_shift_toggle,grp_led:scroll'],

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

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

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

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

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.

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. 

BTW, why "lg,us" and not "us.lg"?

Because Anaconda does 'lg,us' (ie: national keymap is active as default when is
picked up in keyboard config screen). ekanter is right.

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.

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.

Ok.  Does everyone agree that using both Shift keys simultaneously is acceptable
for toggling (grp:shift_toggle)?

actually, gnome-terminal should use something like ctrl+alt+[cv]. ctrl-shift-c
is needed for ISO 140755 unicode hex input.

comment 34: make that ISO 14755

ctrl+shift is frequently used in emacs. Very good point. Please use
grp:shift_toggle.

I agree that ctrl_shift_toggle can brake some things and shift_toggle is the
most safe combination.

Ok, I've converted all toggles in keyboard_models.py to grp:shift_toggle.  I
hope that this resolves this bug report.  Please test with rhpl-0.91-1.

The ideal solution would be to provide (on the keyboard selection screen) a pull
down menu.

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.

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.

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"

Since no developer responded on a comment
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=79287#c28 there is a very
high probability that it was not implemented for languages other then Russian.

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.

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 ***

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".

argh..  bugilla goofed me there.

Setting back to MODIFIED pending original reporter's feedback on testing
existing packages for the problem reported in the original comment.

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.