Red Hat Bugzilla – Bug 602145
Keyboard layout is reset after logging in
Last modified: 2011-06-27 13:51:40 EDT
Description of problem:
Each time I login I see the keyboard layout USA² "USA International (with dead keys)".
The layout is reset to USA²
The previous layout is kept
When I was installing Fedora, I chose "USA International (with dead keys)", so perhaps the layout is stuck in some system configuration.
Same here. You may want to have a look at this side:
For some reasons the file "/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf" isn't keept in sync with the keyboard layout setup.
The issue does not seem to be related to the text console keyboard stuff (kbd), reassigning to probably more accurate component.
(In reply to comment #1)
> Same here. You may want to have a look at this side:
> For some reasons the file "/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf"
> isn't keept in sync with the keyboard layout setup.
Felipe, are you able to fix your keyboard by playing with this file? If yes, could we ask for patch?
(In reply to comment #3)
> (In reply to comment #1)
> > Same here. You may want to have a look at this side:
> > https://fedoraproject.org/wiki/Input_device_configuration
> > For some reasons the file "/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf"
> > isn't keept in sync with the keyboard layout setup.
> Felipe, are you able to fix your keyboard by playing with this file? If yes,
> could we ask for patch?
Yeah, editing /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf works:
Option "XkbOptions" "terminate:ctrl_alt_bksp,"
However, as the comment says:
# This file is autogenerated by system-setup-keyboard. Any
# modifications will be lost.
system-setup-keyboard reads the settings from /etc/sysconfig/keyboard and it's started up by upstart: /etc/init/system-setup-keyboard.conf.
Not to mention that:
% rpm -q --whatprovides /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf
file /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf is not owned by any package
IMO the problem is in GNOME... 00-system-setup-keyboard.conf is a *system* setting, and every user should be able to override it in gnome-keyboard-properties.
(In reply to comment #4)
> IMO the problem is in GNOME... 00-system-setup-keyboard.conf is a *system*
> setting, and every user should be able to override it in
You are probably right. Still, before passing the bug to Gnome folks, can I get /var/log/Xorg.0.log from you attached to this bug, please? Is there anything special about your keyboard worthy to be noted?
Created attachment 425961 [details]
with each new gnome session I get two keyboard layouts: usa and de. When I remove the usa layout and logout and login again. both are back again.
Thomas: what layout is selected on the gdm screen?
If you manually selected one there at any time in the past, this selection will move over into the session and add to the session-configured ones. Once you change that back to "de", that problem goes away.
Oops! You are right! What a stupid mistake on my side! Thanks for the clarification!
(In reply to comment #7)
> Thomas: what layout is selected on the gdm screen?
> If you manually selected one there at any time in the past, this selection will
> move over into the session and add to the session-configured ones. Once you
> change that back to "de", that problem goes away.
I've never selected any language on the GDM screen. It might have been carried out by anaconda though.
I observed a similar issue. After I configure the keyboard layouts to have US (alternative international) and Russian on the next login I will have the system layout (US basic) added as the third layout.
As a workaround I have edited 00-system-setup-keyboard.conf to point to the first layout (US alt-intl) and removed /etc/init/system-setup-keyboard.conf so the altered config would not be overwritten by system-setup-keyboard.
It looks like this is a duplicate of bug 552397.
(In reply to comment #11)
> It looks like this is a duplicate of bug 552397.
I am not sure. The problem for me is that System->Preferences->Keyboard allowed to select much more layouts than system-config-keyboard. When the layouts in preferences do not match the layout coming from system-config-keyboard, then the layout present on the GDM login screen is added to the list of layouts.
Isn't that fully explained by bug 552397#12:
If the user makes any keyboard layout choice in gdm then it is stored in
~/.dmrc (or always?) and overrides whatever has been configured in
AFAICS all the reported cases (including this) can be explained and "works as intended". So the _real_ issue here is that us users don't _understand_ the intentionen. The solution might be to either change the intention or to change the user interface to communicate the intention better.
(In reply to comment #13)
> If the user makes any keyboard layout choice in gdm then it is stored in
> ~/.dmrc (or always?) and overrides whatever has been configured in
As a user I have *not* made any keyboard choice in GDM. I.e. I have not touched the keyboard choice on that screen. GDM forced that on me ignoring my preference that I made in the previous session. If this cases when user has not selected anything on the GDM screen is covered by the bug 552397, then lets make this as a dup.
> AFAICS all the reported cases (including this) can be explained and "works as
Well, the "intended" is rather weird here. I would be happy if GDM on the login screen would show not the system keyboard layout by default but rather something like "user-default". The latter option would respect user's preferences.
(In reply to comment #14)
> As a user I have *not* made any keyboard choice in GDM.
Well ... Accepting what GDM is a kind of choice too. We have the option to choose another layout in GDM, and if it matches what has been configured in Gnome then everything works fine, AFAICS.
> Well, the "intended" is rather weird here. I would be happy if GDM on the login
> screen would show not the system keyboard layout by default but rather
> something like "user-default".
GDM already does that (stored in /var/cache/gdm).
> The latter option would respect user's preferences.
I wouldn't like it if GDM read and used a users gconf before he was logged in, but I agree that it could be nice if Gnome Keyboard Properties could update /var/cache/gdm too.
(In reply to comment #15)
> Well ... Accepting what GDM is a kind of choice too.
I guess the issue is about how to discover the intentions. There are number of layouts that are pretty much the same from the point of view of entering login passwords, like US/US Alt international. The difference is only relevant after the login when one wants to enter some non-latin character that cannot present in passwords. So when I see the US keyboard selected on the login screen I just accept it as a choice to enter my password in a natural way. So it is very surprising to see that layout added to the list of layouts after the login.
I.e the choice of the layout on the login screen in my case is not relevant to the layouts after the login.
> I wouldn't like it if GDM read and used a users gconf before he was logged in,
> but I agree that it could be nice if Gnome Keyboard Properties could update
> /var/cache/gdm too.
After some considerations for me a preferred behavior is for gnome-session to ignore the layout coming from the GDM if that matches the system layout and if the user altered layouts using keyboard preferences.
In the mean time I just accept that I have to pay attention to what I select on the GDM login screen or do a workaround like one in the comment 10.
Even after re-reading this bug again, I don't see anything which would be relevant for xorg-x11-* universe. Reassigning to gnome-session for further analysis.
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.