Bug 476871 - GDM uses wrong keyboard layout after switching back
GDM uses wrong keyboard layout after switching back
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: jmccann
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-17 11:54 EST by Vitaliy S
Modified: 2015-01-14 18:22 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-31 23:22:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for gdm/daemon/gdm-session-direct.c, gdm/daemon/gdm-session-settings.c (2.13 KB, patch)
2009-09-04 03:24 EDT, fujiwara
no flags Details | Diff
Patch for gnome-settings-daemon/plugins/keyboard/gsd-keyboard-xkb.c (679 bytes, patch)
2009-09-04 03:46 EDT, fujiwara
no flags Details | Diff

  None (edit)
Description Vitaliy S 2008-12-17 11:54:28 EST
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.
Comment 1 Ray Strode [halfline] 2008-12-17 11:59:18 EST
can you attach /etc/sysconfig/keyboard ?
Comment 2 Vitaliy S 2008-12-17 12:36:00 EST
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?
Comment 3 Ray Strode [halfline] 2008-12-17 12:51:24 EST
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
Comment 4 Vitaliy S 2008-12-17 13:07:57 EST
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"
Comment 5 Vitaliy S 2008-12-17 17:55:46 EST
I changed the 
KEYTABLE to "us" and it fixed the problem.

Thank you.
Comment 6 Jens Petersen 2008-12-17 19:22:17 EST
Looks similar to bug 474011.
Comment 7 Jens Petersen 2008-12-19 01:09:52 EST
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
Comment 8 Jens Petersen 2008-12-19 02:05:33 EST
This is now reproducible in gdm-2.25.2-2.fc11 too fwiw.
Comment 9 Jens Petersen 2009-07-07 00:35:32 EDT
still happens in rawhide with gdm-2.26.1-13.fc12.
Comment 10 fujiwara 2009-09-04 03:24:00 EDT
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.
Comment 11 fujiwara 2009-09-04 03:46:45 EDT
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.
Comment 12 Ray Strode [halfline] 2009-10-05 12:44:56 EDT
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.
Comment 13 fujiwara 2009-10-05 21:10:26 EDT
(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.
Comment 14 fujiwara 2009-10-21 05:31:11 EDT
Now two upstreamed bugs are filed:
https://bugzilla.gnome.org/show_bug.cgi?id=572765
https://bugzilla.gnome.org/show_bug.cgi?id=585290
Comment 15 fujiwara 2009-10-29 01:38:04 EDT
I think now the Fedora 12 rawhide fixes this problem.
Please close this bug.

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