Description of problem: Can't change keyboard layout in GDM by default. Version-Release number of selected component (if applicable): control-center-3.6.2-1.fc18.x86_64 gdm-3.6.1-1.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. Login as existing user to Gnome. 2. Add new keyboard layout and switch to it. 3. Create new user using "User Accounts". 4. In "User Accounts" set password for new user using new keyboard layout. Use local alphabet characters. 5. Logout and try login as new user. Actual results: There is no keyboard layout switcher. You can't login as new user, because you can't input local alphabet characters. Expected results: When you input password in "User Accounts" using non-system keyboard layout, this layout should be selectable in GDM. Additional info: I've found a workaround, but this can prevent many users from logging in when they change their own password and use local alphabet characters. In "Region & Language" on tab "System" click on "Copy Settings". Then keyboard layout switcher becomes available in GDM.
Do this issue also cover the screen saver? I had set a "strange" keyboard layout while testing keyboard layout switching ... and when I came back the screen was locked and I couldn't enter the password correctly ;-)
Proposal: "User Accounts" should handle what keyboard layout is used for password input and automatically add it to system keyboard layouts and provide it in GDM.
(In reply to comment #1) > Do this issue also cover the screen saver? > > I had set a "strange" keyboard layout while testing keyboard layout > switching ... and when I came back the screen was locked and I couldn't > enter the password correctly ;-) This is related. When you add new keyboard layout, change password using this layout and then remove this layout. You're stuck at Lock Screen.
But GDM case is only ignorance: Adding keyboard layout isn't enough? I didn't know about some "Copy Settings" button hidden in next tab at "Region & Language" Lock Screen case is: user sabotaged himself by deliberately removing keyboard layout.
Discussed at 2012-11-14 blocker bug meeting: we were unable to come to a conclusion on this bug - stuck at +2/-2 NTH. Will revisit when more people are present.
I tested whether this is also related to anaconda, and it is not. I did a Czech installation in Anaconda with Czech keymap, and I ended up in GDM with Czech keymap by default. Everything OK. So this is just for new keymaps added after installation.
Discussed at 2012-11-19 QA meeting, acting as an NTH review meeting. With the new information, solid rejected NTH: does not affect keymaps added during install, and this is actually working as designed - even if it's a bad design, we shouldn't twiddle with it as NTH. The design is that keymaps added as a user are added *for that user only* (and therefore not for gdm); the 'copy settings system-wide' button is to be used to make the keymap available for all users.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. 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.
Is it any better in F19+? Otherwise, such RFE should be made upstream in GNOME bugzilla.
(In reply to Jens Petersen from comment #9) > Is it any better in F19+? > > Otherwise, such RFE should be made upstream in GNOME bugzilla. (In reply to Adam Williamson from comment #7) > Discussed at 2012-11-19 QA meeting, acting as an NTH review meeting. With > the new information, solid rejected NTH: does not affect keymaps added > during install, and this is actually working as designed - even if it's a > bad design, we shouldn't twiddle with it as NTH. The design is that keymaps > added as a user are added *for that user only* (and therefore not for gdm); It is still exactly like that in Fedora 20, and this means itis not a bug really because it works as designed. > the 'copy settings system-wide' button is to be used to make the keymap > available for all users. In the "gnome-control-center region" setup, there is a button [Login Screen] in Fedora 20 where one can add keyboard layouts to be used in gdm. So this all works as designed.
Created attachment 859548 [details] adding-user-with-different-keyboard-layout.png How this looks in Fedora 20.
Working as designed -> closing as NOTABUG.
yeah, I don't think there's any value to this being open downstream any longer. the idea that the keyboard layout used to set the password for a user should be added to the system-wide layouts if it's not already there is an interesting one, but it's an upstream thing not a downstream one, and may not be desired upstream. if you still want it, mholec, can you propose it on gnome bz? Thanks.