GNOME Bugzilla – Bug 648749
gdm 3.x doesn't display the currently active keyboard layout and it doesn't offer an option to change it
Last modified: 2016-01-12 21:54:12 UTC
I have two keyboard layouts available when I'm logged in (I used the Region & Language component of the gnome-control-center to add an additional keyboard layout: slovene - sl) and I can choose between them. However, the gdm login screen doesn't display the currently "active" keyboard layout and it doesn't offer the option to change it. This makes it very hard for people to enter the correct password (they have to guess what the active keyboard layout is) or even impossible if they used characters not present in the english layout. Versions of the selected components: control-center-3.0.0.1-3.fc15.x86_64 gnome-shell-3.0.0.2-2.fc15.x86_64 gdm-3.0.0-2.fc15.x86_64
*** Bug 652430 has been marked as a duplicate of this bug. ***
*** Bug 645188 has been marked as a duplicate of this bug. ***
Regression vs 2.3x releases. Pretty much impossible to log in to administer a machine when the the configured layout doesn't match the physical layout (ie, to fix the configuration issue).
we'll get this when it lands in the shell ( bug 641531 )
Should probably be a blocker bug for release, because this is a serious regression for multi-seat machines, especially for installation in public places or in the enterprise.
(In reply to comment #4) > we'll get this when it lands in the shell ( bug 641531 ) First of all, gnome-shell ibus integration won't land until 3.4, see bug 641531#c47. And second, no matter what happens with gnome-shell, this bug also needs to be fixed in gdm-simple-greeter. Displaying the keyboard layout should not be treated as some sort of an optional extra; it is a basic requirement for half of Europe.
I don't disagree that it's an important issue to get fixed, and I agree we need a reasonable answer for fallback. On the other hand, we're a bit stuck over the issue as a whole. GDM can't implement it, itself for the default case, since the shell is what provides the greeter now. We want a consistent story with what the user sees after they log in, anyway. I do have some patches I worked on for RHEL to change the way layout switching works there. I was planning on landing those patches for our fallback story. It would be hard to get these in, though, for 3.2. I'll post them here. Give me a few.
Created attachment 196638 [details] [review] What I did for rhel This is what I did for RHEL. Something similiar to the second patch could be done for the fallback greeter. Not sure if we can get it for 3.2 though. We won't have a story for the default greeter before bug 641531
"We want a consistent story with what the user sees after they log in, anyway." Consistency's great, but if it's going to cost basic functionality for another 6 months on top of the 6 months it's already been missing, I'd argue that a short-term inconsistent solution, even just a workaround, is probably worth having. We do have a shell element already that's capable of switching layouts. If an admin at least has a way to say "here's the set of layouts to use at login-time" or "here's the set of layouts to use by default", even by editing a random text file.
Jeremy, you're totally right and this completely slipped my mind. The shell does currently have a way to switch layouts, and it does work at the login screen. It doesn't have input method integration, but it should be sufficient for a great deal of cases. It basically functionally equivalent to the patch mentioned in comment 8. It should appear automatically if you have multiple layouts configured for the system. The way you do this configuration varies from distro to distro right now. On fedora it's a comma separated list of layouts in the LAYOUT line of /etc/sysconfig/keyboard You can also do it by editing xorg.conf or so.
(In reply to comment #10) > It basically functionally equivalent to the patch mentioned in comment 8. (but for the default greeter i mean, whereas comment 8 is for the fallback greeter) Also, i just gave this a try after posting comment 10 and and it does indeed work fine. I noticed a bug where it shows a menu item it shouldn't, though. I'll file another bug report to track that.
Interesting. I'm unaware of any way to configure this under debian-based installations, without creating an xorg.conf, but that might be acceptable as a stopgap.
I've filed bug 659164 to track the bogus menu item. Jeremy, instead of creating an xorg.conf, you can also drop a file in xorg.conf.d like: Section "InputClass" Identifier "system-layouts" MatchIsKeyboard "on" Option "XkbModel" "pc105" Optoin "XkbLayout "ru,us,es" EndSection or so
Awesome! With a workaround like that, putting this off a bit longer is much less stressful :) Thank you!
Yes, with this workaround, gdm-3.1.x works well enough for now. (I didn't see it before due to a configuration problem on my end.)
If I understood correctly the workaround, the administrator of the machine has to manually add to the system all the layouts that could possibly be used. Which means that if I want to use a given layout (say "Dvorak") on a given machine where I don't have administration rights (because it belongs to the company), it is not possible for me to have my layout at login time. Could someone confirm that point?
(In reply to comment #16) > Which means that if I want to use a given layout (say "Dvorak") on a given > machine where I don't have administration rights (because it belongs to the > company), it is not possible for me to have my layout at login time. Could > someone confirm that point? Yes, that is correct.
Can someone please post an update on this issue. Have the patches been merged to the repository already? What version will have the fix included?
(In reply to comment #18) > Can someone please post an update on this issue. Have the patches been merged > to the repository already? "Attachments" section says "needs-work" status for the patch, and this bug report is in NEW status and not in RESOLVED FIXED status. Hence no news.