I have realized that Gnome 3.16 has introduced a new tab at the keyboard configuration for the input layout of gdm that I was not aware of. After proper configuration, the input layout at gdm works as expected. However, now I do not understand how my previous workaround was solving the problem since I was changing the user configuration and not gdm's. Also, is it advisable that any user can change gdm's layout configuration? I consider this as resolved, but I stressed out that something may be not working properly. Thx.

I reopen the bug since it seems I am not so dumb after all. They keyboard layout configuration window will show a tab (button) to set gdm only to new users. Existing users prior to 3.16 (in the sense they already logged in befor 3.16), won't see that tab (button). I attach screenshots.

Created attachment 301742 [details]
keyboad layout

no tab for old users (above)

tab for new users (below)

*** Bug 748011 has been marked as a duplicate of this bug. ***

I'm also affected by this bug. Some misbehavior described by Cedric.
Arch + GNOME Shell 3.16.1 (GDM GDM 3.16.1.1)

Did you try to create a new user and set the layout configuration for gdm from there?

Umm nope. Why would I want to do that for?

Created attachment 302724 [details]
Keyboard layout

Ok. I just saw your screenshot.I didn't notice they added the option to configure gdm's layout from there. Anyway, taking a look at my config everything seems correct. I have two different layouts (es_ES and en_US) configured. In my case, "es_ES" is the first one in the list so I assume this should be configured as the default one.

I guess removing the "en_US" layout from the login screen configuration would "fix" my problem. However this would be only a temporary workaround and I wouldn't fix the bug.

I posted an screenshot of my current config.

Thanks.

Still reproducible on:

GNOME Shell 3.16.2
GDM 3.16.1.1

Still reproducible on:

GNOME Shell 3.18.1
GDM 3.18.0


... and no one seems to care about it...

Just to be clear: en_US takes precedence over any over any other layout, even if the latter is above former (en_US) on the priority list.

Have you checked the locale?

This is most likely a bug in gnome-control-center, in gnome-shell, or in systemd. I doubt anything is wrong with gdm. Let's move this to gnome-control-center for now, until we figure out for sure what is going on.

(In reply to CedricMC from comment #12)
> Just to be clear: en_US takes precedence over any over any other layout,
> even if the latter is above former (en_US) on the priority list.
> 
> Have you checked the locale?

Hm, this is clearly a bug, but it's strange because I do not experience this problem. My keyboard layouts are a bit different though; in theory, it shouldn't make any difference, but perhaps the specific keyboard layouts at issue matter.

The settings panel is sufficiently confusing that we need to check what's really going on. Can you please post the output of the 'localectl' command? Please also run gnome-control-center from a terminal while changing your login screen keyboard layouts (not your user account layouts, see below) and look for warnings.

(In reply to CedricMC from comment #2)
> I reopen the bug since it seems I am not so dumb after all. They keyboard
> layout configuration window will show a tab (button) to set gdm only to new
> users. Existing users prior to 3.16 (in the sense they already logged in
> befor 3.16), won't see that tab (button). I attach screenshots.

I think our current behavior is confusing and could stand to be reworked... but here it is:

 * Language and keyboard layout are configured separately for the system as a whole and each user account. So you have list of system keyboard layouts, used in gdm, and a list of layouts used for individual users.
 * The keyboard layout list in gdm should be ordered exactly the same as you configure your system layouts in the Region & Language panel. The default layout should be the one placed on top. This works properly for me.
 * If you have one user account on your system, and it is an Administrator user, then changing your locale and keyboard layout in the Region & Language panel changes both the system setting and your user's setting.
 * If your only user account is not an Administrator user, or you have multiple user accounts, then your changes on this panel affect only your own keyboard layout and not the system layouts (used by gdm). For admin users, a button is added to the panel to allow configuring the system keyboard layout. (Not sure if the button is added for standard users or not; if so, it should require authentication. Standard users should not be permitted to change system keyboard layouts.)
 * System layouts (used by gdm) are managed by localed. Run 'localectl' to see them.
 * User-specific layouts are stored in gsettings, 

Note that there has been discussion of moving the user keyboard layout to accountsservice (which Ubuntu has done), which would make it possible for gdm to change the keyboard layout for each individual user. LightDM already does this. that is https://bugs.freedesktop.org/show_bug.cgi?id=63086

So, with all of the above in mind, that is why I have asked to see the output of 'localectl', so we can see what have really been configured. Then we can try to figure out what went wrong....

I was able to workaround this issue by editing:

/etc/X11/xorg.conf.d/00-keyboard.conf

and modifying the option "XkbLayout".

I removed all unused layouts there and it did the trick. Now in GDM I only see one layout which is the one I want to use to type my pass.
Once I'm logged in, gnome still loads all the different layouts I use.

It's a shame such an easy reproducible bug takes so long to get a proper patch upstream.

(In reply to Michael Catanzaro from comment #13)
> (In reply to CedricMC from comment #12)
> > Just to be clear: en_US takes precedence over any over any other layout,
> > even if the latter is above former (en_US) on the priority list.
> > 
> > Have you checked the locale?
> 
> Hm, this is clearly a bug, but it's strange because I do not experience this
> problem. My keyboard layouts are a bit different though; in theory, it
> shouldn't make any difference, but perhaps the specific keyboard layouts at
> issue matter.

This is the same problem I am having. My keyboard layouts are US QWERTY and 
US Dvorak. 'qwerty' and 'dvorak' in /usr/share/kbd/keymaps/i386/.

> The settings panel is sufficiently confusing that we need to check what's
> really going on. Can you please post the output of the 'localectl' command?
> Please also run gnome-control-center from a terminal while changing your
> login screen keyboard layouts (not your user account layouts, see below) and
> look for warnings.

% localectl
   System Locale: LANG=en_US.UTF-8
       VC Keymap: dvorak
      X11 Layout: us,us
     X11 Variant: dvorak,

This is with both qwerty and dvorak and dvorak at the top of the list in gnome-control-center.

% localectl
   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: us,us
     X11 Variant: ,dvorak

This is with both layouts and having qwerty at the top of the list.

Only qwerty and only dvorak are as you would expect, and I don't think relevant.

> I think our current behavior is confusing and could stand to be reworked...
> but here it is:
> 
>  * Language and keyboard layout are configured separately for the system as
> a whole and each user account. So you have list of system keyboard layouts,
> used in gdm, and a list of layouts used for individual users.
>  * The keyboard layout list in gdm should be ordered exactly the same as you
> configure your system layouts in the Region & Language panel. The default
> layout should be the one placed on top. This works properly for me.
>  * If you have one user account on your system, and it is an Administrator
> user, then changing your locale and keyboard layout in the Region & Language
> panel changes both the system setting and your user's setting.
>  * If your only user account is not an Administrator user, or you have
> multiple user accounts, then your changes on this panel affect only your own
> keyboard layout and not the system layouts (used by gdm). For admin users, a
> button is added to the panel to allow configuring the system keyboard
> layout. (Not sure if the button is added for standard users or not; if so,
> it should require authentication. Standard users should not be permitted to
> change system keyboard layouts.)
>  * System layouts (used by gdm) are managed by localed. Run 'localectl' to
> see them.
>  * User-specific layouts are stored in gsettings, 

I agree this is the desired behavior. That is what you were saying right?



% gnome-control-center -v
** (gnome-control-center:1985): DEBUG: Enabling debugging

# Above this is on startup

(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: trying to track new user with uid 1000
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: finding user with id 1000 state 1
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: waiting for user manager to load before finding user with id 1000
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: calling 'ListCachedUsers'
(gnome-control-center:1985): AccountsService-DEBUG: Failed to identify the current session: No data available
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: seat unloaded, so trying to set loaded property
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: Listing cached users, so not setting loaded property
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: Listing cached users, so not setting loaded property
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: ListCachedUsers finished, will set loaded property after list is fully loaded
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: tracking new user with object path /org/freedesktop/Accounts/User1000
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: unrefing manager owned by finished ListCachedUsers call
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: user ask is now loaded
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: user ask was not yet known, adding it
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: tracking user 'ask'
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: not yet loaded, so not emitting user-added signal
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: no pending users, trying to set loaded property
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: Seat wouldn't load, so giving up on it and setting loaded property
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: user manager now loaded, proceeding with fetch user request for user with id 1000
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: finding user with id 1000 state 2
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: Looking for user with id 1000 in accounts service
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: sending user-changed signal for user ask
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: sent user-changed signal for user ask
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: updating user ask
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: Found object path of user with id 1000: /org/freedesktop/Accounts/User1000
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: finding user with id 1000 state 3
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: user with id 1000 fetched
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: finished handling request for user with id 1000
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: unrefing manager owned by fetch user request
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: user ask is now loaded
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: sessions changed (user ask) num=0
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: no pending users, trying to set loaded property
(gnome-control-center:1985): AccountsService-DEBUG: ActUserManager: already loaded, so not setting loaded property

# Above this is on clicking the "Region & Language" tab
# Then I used the arrows to move the two layouts up and down, deleted and re-added the QWERTY layout and got nothing

(gnome-control-center:1985): Gdk-CRITICAL **: gdk_event_get_source_device: assertion 'event != NULL' failed

(gnome-control-center:1985): Gdk-CRITICAL **: gdk_device_get_source: assertion 'GDK_IS_DEVICE (device)' failed

# Above this was on re-adding the Dvorak layout after deleting it (which printed nothing)

(In reply to Andrew from comment #15)                                            
Oops, I wasn't finished editing and I didn't realize "Save Changes" on the website
meant send. I don't want to send the long log file twice, but I do want to add some
more comments.                                                                   
                                                                                 
I meant to put the gnome-control-center logs after the localectl output. I also meant
to say that I have added notes to say when I did certain UI actions in the logs. 
                                                                                 
Also to clairify what behavior I'm seeing, it's just that after rebooting the layout
in gdm is always qwerty at first. If I change it to dvorak on gdm or if I log in and
set the active layout to dvorak and then lock the screen with super+L, the layout is
still dvorak.  Also if I log out the layout in gdm is still dvorak. I also want to
note that the labels in the layout switcher are en_1 for dvorak and en_2 for qwerty.
After a reboot the switcher shows en_2 by default.

OK, thanks Andrew. Your comment confirms that gnome-control-center is doing the right thing, so this is not a gnome-control-center bug. At this point, I'm guessing this must be a gnome-shell bug. (gnome-shell is responsible for the login screen.) gnome-shell no longer tracks bugs on Bugzilla, so I can't move the bug report automatically. Do you want to report it on https://gitlab.gnome.org/GNOME/gnome-shell/issues?

There's no appropriate bug resolution for this... I want RESOLVED MOVED, but our Bugzilla doesn't seem to have that. I'm going to go with RESOLVED OBSOLETE even though this is bug clearly still exists... let's pretend that means "this bug tracker is no longer the appropriate forum for this issue."