Bug 602145 - Keyboard layout is reset after logging in
Summary: Keyboard layout is reset after logging in
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-session
Version: 13
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-09 09:06 UTC by Felipe Contreras
Modified: 2018-04-11 06:49 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-27 17:51:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
xorg log (88.53 KB, text/plain)
2010-06-22 14:55 UTC, Thomas Meyer
no flags Details

Description Felipe Contreras 2010-06-09 09:06:06 UTC
Description of problem:
Each time I login I see the keyboard layout USA² "USA International (with dead keys)".

Actual results:
The layout is reset to USA²

Expected results:
The previous layout is kept

Additional info:
When I was installing Fedora, I chose "USA International (with dead keys)", so perhaps the layout is stuck in some system configuration.

Comment 1 Thomas Meyer 2010-06-16 15:21:21 UTC
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.

Comment 2 Vitezslav Crhonek 2010-06-17 09:49:12 UTC
The issue does not seem to be related to the text console keyboard stuff (kbd), reassigning to probably more accurate component.

Comment 3 Matěj Cepl 2010-06-18 11:08:38 UTC
(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?

Thank you

Comment 4 Felipe Contreras 2010-06-18 11:43:26 UTC
(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:
---
Section "InputClass"
        Identifier      "system-setup-keyboard"
        MatchIsKeyboard "on"
        Option          "XkbOptions"    "terminate:ctrl_alt_bksp,"
EndSection
---

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.

Comment 5 Matěj Cepl 2010-06-18 17:49:10 UTC
(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
> gnome-keyboard-properties.    

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?

Thank you

Comment 6 Thomas Meyer 2010-06-22 14:55:48 UTC
Created attachment 425961 [details]
xorg log

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.

Comment 7 Peter Hutterer 2010-06-22 23:47:01 UTC
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.

Comment 8 Thomas Meyer 2010-06-23 16:58:56 UTC
Oops! You are right! What a stupid mistake on my side! Thanks for the clarification!

Comment 9 Felipe Contreras 2010-06-26 10:02:41 UTC
(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.

Comment 10 Igor Bukanov 2010-10-12 19:02:04 UTC
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.

Comment 11 Mads Kiilerich 2010-10-13 18:09:29 UTC
It looks like this is a duplicate of bug 552397.

Comment 12 Igor Bukanov 2010-10-13 19:08:40 UTC
(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.

Comment 13 Mads Kiilerich 2010-10-13 22:08:14 UTC
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
gnome-keyboard-properties.

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.

Comment 14 Igor Bukanov 2010-10-13 22:20:46 UTC
(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
> gnome-keyboard-properties.

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

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.

Comment 15 Mads Kiilerich 2010-10-14 00:05:01 UTC
(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.

Comment 16 Igor Bukanov 2010-10-14 10:33:51 UTC
(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.

Comment 17 Matěj Cepl 2010-10-19 22:32:21 UTC
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.

Comment 18 Bug Zapper 2011-06-02 11:29:00 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 19 Bug Zapper 2011-06-27 17:51:40 UTC
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.


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