Keyboard layout doesn't change

Thank you for your bug report, could you run "gnome-screensaver --debug" and see what is in the debug log when unlocking fails?

On Thu, Oct 13, 2011 at 1:45 PM, Sebastien Bacher <email address hidden> wrote:
> Thank you for your bug report, could you run "gnome-screensaver --debug"
> and see what isl in the debug log when unlocking fails?

The following log is from:
1) lock screen
2) When password prompt appears, switch keyboard layout to correct
layout for entering password, enter password (fails)
3) Switch back to original layout and try again (fails)
4) kill via tty (where same password is used to login)

http://paste.ubuntu.com/707329/

It seems that it really is getting an incorrect password - one
possibility that could make sense would be if the keyboard layout was
being applied incorrectly. Let me know if there's anything else I can
do.

Can you paste the appropriate section of your auth.log file?

Also, could you paste the output of the following commands:
ls -l /etc/shadow
ls -l /dev/null

Thanks!

On Thu, Oct 13, 2011 at 3:50 PM, Marc Deslauriers
<email address hidden> wrote:
> Can you paste the appropriate section of your auth.log file?
>
> Also, could you paste the output of the following commands:
> ls -l /etc/shadow
> ls -l /dev/null
>
> Thanks!

Oct 13 15:24:19 michael-1015PEM unix_chkpwd[22678]: password check
failed for user (michael)
Oct 13 15:24:19 michael-1015PEM gnome-screensaver-dialog:
pam_unix(gnome-screensaver:auth): authentication failure; logname=
uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=michael
Oct 13 15:24:26 michael-1015PEM unix_chkpwd[22681]: password check
failed for user (michael)
Oct 13 15:24:26 michael-1015PEM gnome-screensaver-dialog:
pam_unix(gnome-screensaver:auth): authentication failure; logname=
uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=michael
Oct 13 15:24:50 michael-1015PEM sudo: michael : TTY=tty1 ;
PWD=/home/michael ; USER=root ; COMMAND=/bin/ls

$ less /var/log/auth.log
$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1014 2011-08-25 10:53 /etc/shadow
$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2011-10-10 08:29 /dev/null

Thanks Marc

Has there been any update on this defect? I have a fresh install of Ocelot, and have the same outputs as Michael for
 * gnome-screensaver --debug
 * ls -l /etc/shadow
 * ls -l /dev/null

I have 4 layouts set up that I switch between using double-shift:
 * English (international AltGr dead keys)
 * English (programmer Dvorak)
 * English (US)
 * English (Dvorak)

My default layout for the login screen is programmer Dvorak.

If I lock the screen manually using Windows + L, and I type the same password (at least as far as keystrokes), regardless of the layout chosen, I cannot log in. However, if I click Switch User, I am back at the initial login screen, where my password works fine.

Therefore, clicking Switch User and entering the correct password there seems to be a workaround.

I can provide any other logs or information required as well.

Hi, I've just had enough of doing CTRL-ALT-F1 login, kill gnome-screensaver etc., to look more into this and can confirm that, at least for me:

With two keyboard layouts (layout1 and layout2)
1) lock the screen with CTRL-ALT-l
2) touch mouse to bring up screensaver dialog
3) switch keyboard layout to layout2 (and note keyboard indicator indicates layout change)
4) enter password *as if layout1 was active* [1]
5) screen is unlocked
6) switch back to layout1

Repeat, but this time skip step 3 - screen is still unlocked. That is, it seems that although the screensaver dialog indicates that it changes the layout - it is always using the one layout. Brian can you confirm this?

If I get a chance, I'll take a look at the source and see if there's something I can pick off.

[1] I had to type it in to an editor as I only know the keystrokes using layout2

Right - here's the same bug as what I've described reported upstream (but found on Ubuntu 11.10 also):

https://bugzilla.gnome.org/show_bug.cgi?id=662992

I'm also running into this regression on a fresh installation of Ubuntu 11.10. I use two keyboard layouts, "dvorak" and "us".

* In the screensaver unlock dialog, switching the keyboard layout correctly updates the layout indicator (using both mouse clicks and the group toggle shortcut), but the switch doesn't actually take effect: the password input is processed according to the primary layout.

* As an experiment, i tried switching to the secondary layout before activating the screensaver, to see if it changes the behavior, but it doesn't seem to: the dialog still "locks" into the primary layout, rather than the secondary.

Upstream gnome-screensaver closed this bug with a comment indicating that the issue is likely in libxklavier, and may be fixed in a newer version. According to Ray Strode, the bug may be fixed by this commit: http://cgit.freedesktop.org/libxklavier/commit/?id=3d12615671ae69b718d23e5eeeed4164eeeb4582

Just to confirm, i'm currently running and seeing the bug with the latest version in Oneiric: libxklavier16 5.1-1ubuntu1

Status changed to 'Confirmed' because the bug affects multiple users.

The libxklavier commit doesn't fix the problem. I've also tested with 5.2, which doesn't fix the problem either.

Can reproduce.

It does seem to change the layout for the session, but not for the lock dialog.

It's a critical bug.

I change the layout for Arab keyboard as defaut and keep french (varaiante) for layout 2. After the session lock, i never could write my password (who is in occidental letter). I try the virtual keyboard but as well i choose arab or french keyboard, i only saw arab letter on the virtual keyboard.
I must go to the terminal and edit /etc/lightdm/lightdm.conf for add this line

[SeatDefaults]
autologin-user=toto
autologin-user-timeout=0
autologin-session=lightdm-autologin

with tooto is my compt's name

Apparently this has been fixed upstream in gtkplug: https://bugzilla.gnome.org/show_bug.cgi?id=675167

upstream commit:
http://git.gnome.org/browse/gtk+/commit/?id=0aa989ae76d0d080eae16b8a4fde59aca1227cc4

"GtkPlug: fix handling of key events for different layouts

GtkPlug directly handles X KeyPress/Release events, instead of using translation in GDK (which expects XI2 events for XI2). When this was done, the handling of the group was stubbed out and never replaced. Export gdk_keymap_x11_group_for_state() and gdk_keymap_x11_is_modifier() so we can fill out the fields correctly. "

I have the same problem . But it appear after logoff/logon action. Keyboard layout indicator disappear from panel and I can't change layout. But after reboot everything fine ubuntu 12.04 (64) .

I found that layout every time changed but only by default key combination. Atl+Shift. If just open keyboard setting and switch on /off any field user settings began work while next reboot.

This bug was fixed in the package gtk+3.0 - 3.4.2-0ubuntu3

---------------
gtk+3.0 (3.4.2-0ubuntu3) quantal; urgency=low

  * debian/patches/git_layouts_handling.patch:
    - git patch to "fix handling of key events for different layouts",
      that should resolve the issues where changing layout was having no
      effect in the lockscreen (lp: #872701)
  * debian/patches/git_allow_null_id.patch:
    - "Really allow NULL application-id"
  * debian/patches/git_custom_tag_start.patch:
    - "Infobar not loadable by GTKBuilder"
  * debian/libgtk-3-0.symbols: list the new symbols
 -- Sebastien Bacher <email address hidden> Tue, 12 Jun 2012 19:40:26 +0200

Hello Michael, or anyone else affected,

Accepted gtk+3.0 into precise-proposed. The package will build now and be available in a few hours. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Could somebody who was having the issue test the update?

Hi,

I can confirm that upgrading to the following precise-proposed packages fixes the behavior here:

libgtk-3-common 3.4.2-0ubuntu0.3
libgtk-3-0 3.4.2-0ubuntu0.3
libgtk-3-bin 3.4.2-0ubuntu0.3
libgail-3-0 3.4.2-0ubuntu0.3

gnome-screensaver's password entry now follows the indicated layout correctly.

@Piet: thanks, setting the bug to verification-done, if no issue is found it will move to precise-updates in 3 days

Confirming that upgrading to libgtk-3-0 from proposed also allows me to unlock using the selected layout. Thank-you to all involved!

This bug was fixed in the package gtk+3.0 - 3.4.2-0ubuntu0.3

---------------
gtk+3.0 (3.4.2-0ubuntu0.3) precise-proposed; urgency=low

  * debian/patches/git_layouts_handling.patch:
    - git patch to "fix handling of key events for different layouts",
      that should resolve the issues where changing layout was having no
      effect in the lockscreen (lp: #872701)
  * debian/patches/git_allow_null_id.patch:
    - "Really allow NULL application-id"
  * debian/patches/git_custom_tag_start.patch:
    - "Infobar not loadable by GTKBuilder"
  * debian/libgtk-3-0.symbols: list the new symbols
 -- Sebastien Bacher <email address hidden> Tue, 12 Jun 2012 19:52:10 +0200

For screen savers it maybe works but not fix that gnome not applying keyboard layout swithers setup after but, only working combination for console.