GNOME Bugzilla – Bug 613666
Default to system settings for handling multiple keyboard layouts
Last modified: 2010-04-01 17:18:48 UTC
From https://launchpad.net/bugs/460328: System wide keyboard layout settings, gdm/$GDM_KEYBOARD_LAYOUT, and g-s-d currently do not work together when the system configures more than one keyboard layout by default (e. g. "XKBLAYOUT=us,de" in udev). This is important for non-Latin languages. E. g. if you normally use a Russian, Greek, or Hebrew layout, you always need an additional alternative Latin layout (usually US) to be able to enter URLs, use keyboard shortcuts and the like. However, right now this does not work: * gdm reads keyboard layouts from system, uses the first one as a selection for the layout picker ("us") in this case * gdm sets GDM_KEYBOARD_LAYOUT=us (or "de", "gr", etc. if you picked a different one in gdm, but always just one). * g-s-d starts:On the first login, /desktop/gnome/peripherals/keyboard/kbd/layouts is empty, and thus g-s-d adds $GDM_KEYBOARD_LAYOUT to it, so that the gconf key becones [us]. This is then kept for subsequent logins. To work around this, users have to re-configure their keyboard layouts in the keyboard capplet. I think gdm's behaviour should stay as it is, i. e. we should not try to make $GDM_KEYBOARD_LAYOUT pass around ordered lists and try to merge them with the gconf key. g-s-d's gconf key should have all the available layouts, and gdm then just picks one which is selected by default. What should happen here is that g-s-d reads the layouts from the system (through libxklavier) if the gconf key is empty. It can either leave the gconf key empty, or write the system layouts into it, but I think in the normal spirit of not writing user configuration unless the user actually set anything actively I'd rather leave it empty.
Created attachment 156850 [details] [review] Keep multiple system keyboard layouts for session I tested this patch with having "us" and "de nodeadkeys" configured in the system, i. e. XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us,de", ",nodeadkeys", "terminate:ctrl_alt_bksp,grp:shifts_toggle" I tested four situations: * Do not touch the keyboard selector in gdm at all. It defaults to "us" (first entry in the XKB list). This essentially doesn't change the configuration for the session at all, I get "us,de" ",nodeadkeys" in the session. * Select a different layout in gdm which is already configured: I pick "de nodeadkeys" in gdm, and end up with "de,us" "nodeadkeys,". * Select a layout which is configured, but with a different variant: I pick "de" (which is with dead keys). This ends up as "de,us,de" ",,nodeadkeys". * Select an entirely different layout: I pick "France", and get "fr,us,de", ",,nodeadkeys". In all cases I booted into an "xterm" session, to ensure that g-s-d etc. does not further modify the settings. I verified that I got the correct keyboard layout and deadkey-ness.
Oops, sorry, above patch should have gone to bug 613681, which fixes the gdm side of this bug.
Created attachment 156873 [details] [review] Default to system settings for handling multiple keyboard layouts This implements the suggested behaviour. If gconf has an empty key, and $GDM_KEYBOARD_LAYOUT contains a layout which is already known on the system level (i. e. in X' root window property "_XKB_RULES_NAMES"), gconf is not changed. Only if I specify a new layout, gconf now gets that new one plus the system layouts. Thanks for considering, Martin
Created attachment 156877 [details] [review] Fix keyboard indicator displaying While experimenting with g-s-d I noticed that the indicator was often not displayed when I had multiple layouts available. I think we always want to show the indicator if we have multiple keyboard layouts available, not just if we set a different keyboard layout.
Sergey? Matthias (IIRC you had your fingers in these parts before, too)?
Yes, these patches look reasonable for me. Is the issue critical enough to break the freeze? I guess not really, can wait till release. Martin, what do you think?
(In reply to comment #6) > Yes, these patches look reasonable for me. Is the issue critical enough to > break the freeze? I guess not really, can wait till release. Martin, what do > you think? I don't think they are critical or obvious [1] enough for a freeze breakage. 2.30.1 is certainly enough. Also, there's a workaround of manually configuring layouts, which is inconvenient, but not the end of the world either. I applied the patches to the Ubuntu package for now, I'll followup with any regression report. BTW, I just got a followup in the downstream bug that there's still a problem with multiple layouts if you move them up and down in gnome-keyboard-preferences. This might be a bug in control-center or an underlying library. I'll investigate this in the next days and follow up. Thanks, Martin [1] It took me some 4 hours to truly understand, fix, and test the issue from end to end (udev rules -> X -> root properties -> libxklavier -> libgnomekbd -> gdm/g-s-d) --- this stuff is pretty complex :-/. So let's not risk regressions by rushing it through the freeze.
(In reply to comment #7) > BTW, I just got a followup in the downstream bug that there's still a problem > with multiple layouts if you move them up and down in > gnome-keyboard-preferences. This might be a bug in control-center or an > underlying library. I'll investigate this in the next days and follow up. I looked at this, it should be a trivial fix. I filed bug 613775 about this. It is also totally independent from the gdm and g-s-d fixes.
Now that the freeze is over, committed. Thanks!
Sergey, thanks, but you only committed the second (smaller) patch, not the main patch. Am I ok to push that, too?
Sorry, overlooked the first one. There.