Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Doesn't configure multiple language setups properly with new xkb model|
|Product:||[Retired] Red Hat Linux||Reporter:||Leonid Kanter <leon>|
|Component:||redhat-config-keyboard||Assignee:||Brent Fox <bfox>|
|Status:||CLOSED RAWHIDE||QA Contact:||David Lawrence <dkl>|
|Version:||9||CC:||aleksey, ekanter, eng-i18n-bugs, mharris, milan.kerslager, otaylor|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-05-25 10:31:14 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Leonid Kanter 2002-12-09 11:39:34 EST
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): XFree86-188.8.131.52-0.20021126.8 How Reproducible: always 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 02:27:24 EST
Sounds to me like a redhat-config-keyboard but I could be wrong.
Comment 2 Eugene Kanter 2002-12-14 14:35:52 EST
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 14:37:31 EST
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 06:29:50 EST
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 06:31:13 EST
Any comments Owen?
Comment 6 Leonid Kanter 2002-12-19 07:03:07 EST
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 07:11:01 EST
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.
Comment 8 Leonid Kanter 2002-12-19 09:46:21 EST
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 184.108.40.206 server only.
Comment 9 Owen Taylor 2002-12-19 11:58:39 EST
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 13:02:15 EST
Oven, did you see bug 75109? The input method behaviour is very different in GNOME and KDE.
Comment 11 Owen Taylor 2002-12-19 13:17:51 EST
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 06:38:01 EST
>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 firstname.lastname@example.org, or you can discuss the issue in the open email@example.com 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.
Comment 13 Aleksey Nogin 2003-01-06 02:31:34 EST
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 18:32:02 EST
You can file a bug report at firstname.lastname@example.org, or you can discuss the issue in the open email@example.com 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.
Comment 15 Leonid Kanter 2003-01-23 05:56:12 EST
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?
Comment 16 Mike A. Harris 2003-01-23 06:51:18 EST
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 14:51:05 EST
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 15:51:19 EST
*** Bug 80141 has been marked as a duplicate of this bug. ***
Comment 19 Milan Kerslager 2003-01-23 16:26:22 EST
Beta 4 is still the same like Beta 3. So changing version.
Comment 20 Mike A. Harris 2003-01-24 01:03:07 EST
*** Bug 80141 has been marked as a duplicate of this bug. ***
Comment 21 Leonid Kanter 2003-02-07 09:29:34 EST
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.
Comment 22 Leonid Kanter 2003-02-07 09:39:56 EST
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 10:50:32 EST
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 14:46:29 EST
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 elif item == "options": - return "" + return kb elif item == "name": return kb 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 15:49:19 EST
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 16:02:48 EST
"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
Comment 27 Brent Fox 2003-02-07 18:34:47 EST
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.
Comment 28 Eugene Kanter 2003-02-09 14:11:47 EST
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 16:17:49 EST
BTW, why "lg,us" and not "us.lg"?
Comment 30 Milan Kerslager 2003-02-09 16:26:58 EST
Because Anaconda does 'lg,us' (ie: national keymap is active as default when is picked up in keyboard config screen). firstname.lastname@example.org is right.
Comment 31 Milan Kerslager 2003-02-11 13:49:32 EST
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 14:05:13 EST
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 14:16:44 EST
Ok. Does everyone agree that using both Shift keys simultaneously is acceptable for toggling (grp:shift_toggle)?
Comment 34 Eido Inoue 2003-02-11 15:17:45 EST
actually, gnome-terminal should use something like ctrl+alt+[cv]. ctrl-shift-c is needed for ISO 140755 unicode hex input.
Comment 36 Eugene Kanter 2003-02-11 15:49:34 EST
ctrl+shift is frequently used in emacs. Very good point. Please use grp:shift_toggle.
Comment 37 Leonid Kanter 2003-02-11 15:56:01 EST
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 16:31:07 EST
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.
Comment 39 Eugene Kanter 2003-02-11 18:44:37 EST
The ideal solution would be to provide (on the keyboard selection screen) a pull down menu.
Comment 40 Brent Fox 2003-02-11 18:55:36 EST
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-11 19:39:17 EST
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 13:53:52 EST
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 14:31:03 EST
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.
Comment 44 Mike A. Harris 2003-03-06 16:53:43 EST
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 17:15:34 EST
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 17:49:19 EST
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 17:49:48 EST
argh.. bugilla goofed me there.
Comment 48 Mike A. Harris 2003-03-06 17:51:01 EST
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 10:31:14 EDT
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.