Description of problem: After upgrade from fedora 9 to fedora 10 via yum the GDM uses keyboard layout for login/password input different from English despite English was the default keyboard layout. The login screen is written in English while the input uses Russian keyboard layout. Russian (wasn't a primary locale before update, neither it was primary keyboard layout). Also, there is not way to switch keyboard layout in GDM, the previous key combination do not work. Version-Release number of selected component (if applicable): gdm-2.24.0-12.fc10.i386 How reproducible: install fedora 9 set default keyboard to english set secondary keyboard layout to russian upgrade to fedora 10 try to enter the login in theGDM Actual results: the GDM uses Russian keyboard layout Expected results: the GDM uses English keyboard layout Additional info: As far as I know this happened because now HAL responsible for keyboard layout while before the update xorg.conf was in charge.
can you attach /etc/sysconfig/keyboard ?
I'll try, can you tell how to log into such system and what should be placed into /etc/sysconfig/keyboard to make it work?
hit ctrl-alt-f2 type your username type your password run su - type root's password run /sbin/init 3 then type "exit" and then type startx From there you should be at your normal logged in session
Thank you, I'll try that. On the other PC GDM stop responding on keyboard or mouse events at all after upgrade, should I open it as another bug? BTW, this fedora has similar configuration to the one I described before (and I can connect via ssh to it). cat /etc/sysconfig/keyboard KEYBOARDTYPE="pc" KEYTABLE="ru"
I changed the KEYTABLE to "us" and it fixed the problem. Thank you.
Looks similar to bug 474011.
Here is another example: Steps to Reproduce: 1. boot F10 Live 2. login with default US layout as liveuser 3. set a passwd for liveuser 4. logout 5. input passwd in US layout 6. select Nepal keyboard 7. click on Login 6. input text 7. logout 8. switch to US layout and login again 9. input text 10. logout and login again in US Actual results: 9. input in app is still in Nepali even though US 10. seems no way to bring desktop kbd layout back to US even though gdm itself respects kbd setting for passwd Expected results: 9. should be US ascii input 10. desktop kbd layout to follow gdm setting consistently
This is now reproducible in gdm-2.25.2-2.fc11 too fwiw.
still happens in rawhide with gdm-2.26.1-13.fc12.
Created attachment 359765 [details] Patch for gdm/daemon/gdm-session-direct.c, gdm/daemon/gdm-session-settings.c The part "gdm-session-direct.c:" setup_session_environment() is fixed in HEAD and it's against a Fedora internal patch gdm-system-keyboard.patch . The following scenario is the bug reproducing steps: 1. default system keyboard layout is jp from /etc/sysconfig/keyboard 2. GDM layout option Widget shows jp layout by default. 3. Users can add us layout from layout dialog. 4. Log in to GNOME session with us layout. 5. GDM worker sends GDM_KEYBOARD_LAYOUT="us" 6. GDM worker saves Layout=us in $HOME/.dmrc 7. gnome-settings-daemon gets "us" from GDM_KEYBOARD_LAYOUT and save it in gconf value /desktop/gnome/peripherals/keyboard/kbd/layouts = [us] And update XKB layout with xkl_engine_lock_group(). 8. Log out the GNOME session. 9. GDM layout option Widget shows us layout. 10. Log in to GNOME session with jp layout. Then GDM worker does *not* send GDM_KEYBOARD_LAYOUT="jp" Because get_layout_name (session) == "jp" from layout Widget and get_system_default_layout (session) == "jp" from /etc/sysconfig/keyboard and setup_session_environment() doesn't set GDM_KEYBOARD_LAYOUT with the fedora patch gdm-system-keyboard.patch . 11. GDM worker saves Layout=jp in $HOME/.dmrc 12. gnome-settings-daemon doesn't get $GDM_KEYBOARD_LAYOUT. It sets XKB layout "us" from the gconf value. So user choose "jp" layout but actual session assigns "us" layout. To fix this problem, I think removing the if condition is good. get_layout_name() returns the layout from GUI. get_system_default_layout() returns the system layout. get_default_layout_name() returns saved layout in .dmrc. The default layout is retrieved from user's gconf value so the either get*() doens't return the correct value. I also think checking user's gconf is not good before gnome-settings-daemon is launched. The fix of gdm_session_settings_set_layout_name() means to call "layout-name" notification in reading .dmrc only. gdm_session_settings_set_layout_name() is also called when users choose the layout from GUI. If "layout-name" notification is called with users choice, the notification calls a DBUS method and gdm-simple-slave updates GdmSessionDirectPrivate.saved_layout as the result. This fix GDM always can send $GDM_KEYBOARD_LAYOUT. I'm also adding gnome-settings-daemon patch.
Created attachment 359766 [details] Patch for gnome-settings-daemon/plugins/keyboard/gsd-keyboard-xkb.c The gnome-settings-daemon codes update the initial layout only so if users change the layout on GDM layout option Widget again, the gconf value is not updated and xkl_engine_lock_group() is not called. After this patch is applied: 1. Invoke gnome-keyboard-properties 2. Select [Layouts] tab. 3. Disable [Separate layout for each window]. Then GDM layout setting can send to all application Windows.
You don't want to always send GDM_KEYBOARD_LAYOUT because then the users choice from within the session (from gnome-keyboard-properties) would get ignored.
(In reply to comment #12) > You don't want to always send GDM_KEYBOARD_LAYOUT because then the users choice > from within the session (from gnome-keyboard-properties) would get ignored. Is it the implementation for gnome-settings-daemon instead of GDM? My concern is that GDM cannot get the current user's layout without gconfd but if GDM calls user's gconfd to check the user's layout, it would be possible double gconfd, one is from GDM and another is from gnome-session. If GDM always send GDM_KEYBOARD_LAYOUT, gnome-settings-daemon could implement if it uses the enviroment or get the value from gconf value.
Now two upstreamed bugs are filed: https://bugzilla.gnome.org/show_bug.cgi?id=572765 https://bugzilla.gnome.org/show_bug.cgi?id=585290
I think now the Fedora 12 rawhide fixes this problem. Please close this bug.