Changing keyboard layout in control-center should update default gdm layout in .dmrc

Bug #546785 reported by Eneko Pérez on 2010-03-25
90
This bug affects 16 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Fix Released
Medium
gnome-settings-daemon (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: gnome-control-center

gnome-keyboard-properties don't remember your keyboard layouts. When you add a new one and select it, it works ok. At the next login, USA layout will remain (even if you deleted it before) and will be the default layout on the system, forcing you to change it at every login.

Description: Ubuntu lucid (development branch)
Release: 10.04

gnome-control-center:
  Installed: 1:2.29.92-0ubuntu1
  Candidate: 1:2.29.92-0ubuntu1
  Version table:
 *** 1:2.29.92-0ubuntu1 0
        500 http://es.archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: i386
CheckboxSubmission: 1ac714b8ba2a7cda2bcb192fec89c7e5
CheckboxSystem: f134069bba098730d27f59b402920826
Date: Thu Mar 25 11:45:08 2010
DistroRelease: Ubuntu 10.04
ExecutablePath: /usr/bin/gnome-keyboard-properties
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100318)
Package: gnome-control-center 1:2.29.92-0ubuntu1
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
SourcePackage: gnome-control-center
Uname: Linux 2.6.32-16-generic i686
XsessionErrors:
 (polkit-gnome-authentication-agent-1:1371): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-terminal:1752): Gtk-CRITICAL **: gtk_accel_map_unlock_path: assertion `entry != NULL && entry->lock_count > 0' failed

Eneko Pérez (eneko-perez) wrote :
Colin Stephen (colin-stephen) wrote :

I found the same problem on 9.10 but only on my wife's account. Despite setting the preference system wide for UK layout and deleting the US layout it would return on next login frustratingly.

In my case this was because the layout preference in the discreet bar at the bottom of the GDM login screen had been set to US at some stage. GDM remembered this preference and would restore it on each login overriding the Gnome preference.

Whilst it's trivial to fix when you spot it, it is very frustrating and a very bad user experience that such a fundamental thing as the keyboard layout "is broken". There must be some way to unify / synchronise the GDM preference with the desktop preference.

Changed in gnome-control-center (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Eneko Pérez (eneko-perez) wrote :

Hi Colin,

Yes. I think it's totally related to the gdm setup. The point is: should 'gdm' remember what the keyboard preferences panel says or viceversa?

Anyway, this should in fact be unified somehow. Since Linux is a multi-user operative system, the gdm setup makes sense. The system doesn't know who is going to log in. The important thing is that, no matter what the user sets under the keyboard preferences, it becomes overwritten once and again.

Martin Pitt (pitti) wrote :

Indeed gdm is currently "more" authoritative. The selected layout in gdm will be the default layout in the session, and will be added to the configured layouts if it wasn't there yet. This is pretty much a design decision in GNOME, and will not change. Eneko, can you confirm that things work alright if you select the right layout in gdm?

Changed in gnome-control-center (Ubuntu):
status: New → Incomplete
assignee: Martin Pitt (pitti) → nobody
Colin Stephen (colin-stephen) wrote :

Hi Eneko,

The GDM preference bar only pops up once the user is selected, just as the password entry box appears. Looks like this allows it to recall per-user preferences from their last login at that point as my account defaulted to the correct layout.

It's easy for GDM to set an overriding keyboard layout via the environment variable (GDM_KEYBOARD_LAYOUT?) and for Gnome to respect that. That happens now. The trouble is when a user sets a preference in Gnome (or KDE etc), that doesn't get communicated to GDM - it would need to update the preference in GDM somehow before a desktop is invoked. Alternatively Gnome would need to know that the user didn't explicitly choose an overriding layout in GDM.

The user experience should be that the keyboard layout should be whatever they set it to the last time they chose one.

Colin Stephen (colin-stephen) wrote :

If the gdm selection is the authoritative one, can I suggest that the Gnome keyboard preference panel warns the user that their preference may be overridden by gdm on the next login ?

If there was some warning, at least when they change their Gnome keyboard preferences to remove $GDM_KEYBOARD_LAYOUT from the list, it would save some confusion.

Eneko Pérez (eneko-perez) wrote :

Hi Colin, Martin:

Changing the value from the 'gdm', before I do login, it works well. I understand it's this way by design. It doesn't make much sense to me anyway. I would suggest two things:

The first one, an easy way to change the default layout for the gdm (through a gdm preferences panel or something like that).

The second one, I'd suggest to change the thing, just to take care of the users' preferences. If under my profile I selected, for example, UK, why gdm doesn't respect this point? I mean, it's ok that it has to be a default layout. But this default layout should be "overwritten" with the users' choice. If not, what is the users' preferences for?

In my case for example, I like to run Ubuntu in english. But, I need my own keyboard layour, which is Spain Macintosh.

I'm pretty sure that if, during installation of the system, I choose Spanish as system language, then gdm would set spanish as default layout.

Any of the two things I suggest would be enough to solve this "issue" or design.

Thanks,

Eneko

Martin Pitt (pitti) wrote :

> The trouble is when a user sets a preference in Gnome (or KDE etc), that doesn't get communicated to GDM - it would need to update the preference in GDM somehow before a desktop is invoked.

Yes, that makes sense. That "somehow" particular means to change "Layout" in ~/.dmrc and /var/cache/gdm/$USER/dmrc.

Setting bug to triaged, as it's fully understood now. Thanks for the report!

Changed in gnome-control-center (Ubuntu):
importance: Undecided → Low
status: Incomplete → Triaged
summary: - keyboard layouts don't remain
+ Changing keyboard layout in control-center should update default gdm
+ layout in .dmrc
Eneko Pérez (eneko-perez) wrote :

Remember the multi-user purpose of Linux. There should be a way to change the default layout for 'gdm'.

If it's not, then 'gdm' default keyboard layour should NOT override the users' settings.

That's how, in my humble opinion, it should work.

Eneko

Eneko Pérez [2010-03-25 12:44 -0000]:
> Remember the multi-user purpose of Linux. There should be a way to
> change the default layout for 'gdm'.

It's a per-user setting (~/.dmrc). If the user never selected a layout
in gdm, it uses whatever the system default is.

Eneko Pérez (eneko-perez) wrote :

I have additional information.

In the login window, 'gdm', selecting a different keyboard layout changes your .dmrc file for that session.

For example, if choose Spanish, then the 'layout' option inside .dmrc file is changed to spanish, which is great.

If we choose 'USA', which is by default in english installations of ubuntu, from the layout menu at 'gdm', then the 'layout' option under your .dmrc file shows 'us'.

So, not only changing keyboard layout in control-center should update default gdm layout in .dmrc. Something needs to be done to avoid 'gdm' to overwrite users' .dmrc 'layout' option (if previously established under control-center).

Cheers,

Eneko

renegat (rozbujnik) wrote :

Problem still remains in meveric meerkat. I installed system with defalt layout (for my country), then I added dvorak layout. Keyboard shortcuts just do not work if I operate on new layout!!!!

This is a major issue, this should not be happening!

Ola Lindberg (olalindberg) wrote :

Having the same issue. Added a thread in Ubuntuforums (http://ubuntuforums.org/showthread.php?t=1632964).

Even if I choose Belarus (Latin) keyboard in gdm and get the following contents of .dmrc:

[Desktop]
Language=en_US.utf8
Layout=by latin

I have USA layout added to my keyboard setup. Any known workaround for this behavior?

I use Ubuntu 10.10.

affects: gnome-control-center → gnome-settings-daemon
affects: gnome-control-center (Ubuntu) → gnome-settings-daemon (Ubuntu)

I've uploaded custom gnome-settings-daemon package with this bug fixed (completely ignoring GDM layout in user sessions). You can get it from: https://launchpad.net/~ihar-hrachyshka/+archive/ppa
The fix is backported from GNOME master git branch: http://git.gnome.org/browse/gnome-settings-daemon/patch/?id=7fdb0c0de728b6a7a90475defb1af0f36c359f79

Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: Unknown → Fix Released
Martin Pitt (pitti) wrote :

Note that this isn't an appropriate fix for Natty. Our gdm still does allow changing the keyboard layout, and I think it should continue to be respected.

I don't think this should be respected in any way - that seems like the right behavior for user session settings: user gconf settings should *replace* gdm settings, not *merge* with gdm one. What do you think?

Martin Pitt (pitti) wrote :

booxter [2011-02-27 10:25 -0000]:
> I don't think this should be respected in any way - that seems like the
> right behavior for user session settings: user gconf settings should
> *replace* gdm settings, not *merge* with gdm one. What do you think?

Yes, I do agree that changing the layout in control-center should also
update ~/.dmrc.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

You should think the case of a user with international US keyboard in his notebook that occasionally attaches an external keyboard with different language. When I change my keyboard setting within Gnome, it keeps returning (randomly?) to GDM configuration. That's not the behaviour I expect. Sometimes I use KDE and it keeps my setting through the entire session.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.