X defaulting keyboard locale to US at login by a keyboard paired with Logitech Unifying Receiver

Bug #995715 reported by Montblanc on 2012-05-07
112
This bug affects 23 people
Affects Status Importance Assigned to Milestone
xserver-xorg-input-evdev (Ubuntu)
Undecided
Unassigned

Bug Description

After upgrading Kubuntu Oneiric to Precise, X locale is defaulted to en_US regardless of system-wide and user-specific options.

I found out about this issue when I tried to login via the KDM greeter and it was not recognizing my password. I got pam authentication failures in the auth.log, but authorizations files were just fine. In fact, I could login from the console and within KDE itself. When I tried typing into the KDM username box, I found out that special characters were not corresponding to my it_IT layout. My password was including the special character @ that was typed as ; thus not accepting my password. I worked this around by changing password to not include any special character.

I installed LightDM and the problem persisted, so I thought about an evdev bug.

I posted this issue on the Kubuntu Forums at first, where you can find more information and logs [ http://www.kubuntuforums.net/showthread.php?58623-Can-t-login-via-KDM-after-upgrading-to-Precise ].

Recently, German users were experiencing the same problem [ http://forum.ubuntuusers.de/topic/kein-login-in-kdm-nach-upgrade/ ] where I found out that the only thing in common is a wireless keyboard.

I bought a Logitech K800 (which uses a Unifying Receiver) when I was running Oneiric, making this the first time I upgraded a distribution while a wireless keyboard is connected. If that happens to be the problem, it could mean that my keyboard locale was not recognized during the upgrade process.

I'm attaching some configuration files and logs, please tell me if you need more information.

$ lsb_release -a
LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch
Distributor ID: Ubuntu
Description: Ubuntu 12.04 LTS
Release: 12.04
Codename: precise

$ uname -a
Linux melchior 3.2.0-24-generic-pae #38-Ubuntu SMP Tue May 1 16:40:26 UTC 2012 i686 athlon i386 GNU/Linux

$ apt-cache policy xserver-xorg
xserver-xorg:
  Installato: 1:7.6+12ubuntu1
  Candidato: 1:7.6+12ubuntu1
  Tabella versione:
 *** 1:7.6+12ubuntu1 0
        500 http://it.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

$ apt-cache policy xserver-xorg-input-evdev
xserver-xorg-input-evdev:
  Installato: 1:2.7.0-0ubuntu1
  Candidato: 1:2.7.0-0ubuntu1
  Tabella versione:
 *** 1:2.7.0-0ubuntu1 0
        500 http://it.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

$ apt-cache policy locales
locales:
  Installato: 2.13+git20120306-3
  Candidato: 2.13+git20120306-3
  Tabella versione:
 *** 2.13+git20120306-3 0
        500 http://it.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

$ apt-cache policy console-data
console-data:
  Installato: (nessuno)
  Candidato: 2:1.12-1
  Tabella versione:
     2:1.12-1 0
        500 http://it.archive.ubuntu.com/ubuntu/ precise/universe i386 Packages

$ apt-cache policy kdm
kdm:
  Installato: 4:4.8.3-0ubuntu0.1~ppa2
  Candidato: 4:4.8.3-0ubuntu0.1~ppa2
  Tabella versione:
 *** 4:4.8.3-0ubuntu0.1~ppa2 0
        500 http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status
     4:4.8.2a-0ubuntu4 0
        500 http://it.archive.ubuntu.com/ubuntu/ precise/main i386 Packages

Montblanc (montblanc) wrote :
Montblanc (montblanc) wrote :
Montblanc (montblanc) wrote :
Montblanc (montblanc) wrote :
Montblanc (montblanc) wrote :
Montblanc (montblanc) wrote :
Montblanc (montblanc) wrote :
Montblanc (montblanc) wrote :
Montblanc (montblanc) on 2012-05-07
description: updated
Montblanc (montblanc) wrote :
Montblanc (montblanc) on 2012-05-07
description: updated
tags: added: azerty qwerty qwertz
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in xserver-xorg-input-evdev (Ubuntu):
status: New → Confirmed
flowermachine (flowermachine) wrote :

i am affected by the same problem. i searched google and i found that many distros are affected (gentoo, debian and arch at least) but they solved it adding the locale settings in xorg.conf or evdev but my xorg contains the locale already. this happened after upgrade to 12.04 but i am not sure it is because precise evdev or even ubuntu. it's like a bug in xorg itself.

Montblanc (montblanc) wrote :

@flowermachine Are you using a wireless keyboard? And can you please add your xorg.conf? I search Googled for this problem too and it seems related at first, but people could solve it by adding locale settings to 10-evdev.conf or xorg.conf. I tried both proposed solutions, but it didn't work so I'll keep the bug on Ubuntu and let users select a different distribution if that happens to be the case. Also, are you suggesting I should add the xserver-xorg package to the bug?

Montblanc (montblanc) on 2012-05-08
summary: X defaulting keyboard locale to US at login after upgrading distribution
+ if a Logitech Unifying Receiver is plugged in

Okay, it seems I made some progress. I was right to think the problem was in the keyboard. I tried these steps:

1) Started the machine with a USB keyboard plugged in: KDM detects the correct locale.
2) Started the machine with both USB keyboard and Logitech K800: KDM is detecting the correct locale for BOTH keyboards.
3) Started the machine with Logitech K800 plugged in: wrong locale again.

So the problem seems to be in keyboards locale detection using the Logitech Unifying Receiver.

I could also reproduce the problem:

1) Installed Oneiric on a new partition with a USB keyboard plugged in. (RIGHT LOCALE)
2) Unplugged the USB keyboard and plugged the Logitech Unifying Receiver. (RIGHT LOCALE)
3) Rebooted to KDM. (RIGHT LOCALE)
4) Upgraded to Precise and rebooted to KDM. (WRONG LOCALE)

Montblanc (montblanc) on 2012-05-08
tags: added: logitech receiver unifying wireless
Montblanc (montblanc) wrote :

Please, let me add one last thing. I figured out that when I start the machine while my keyboard is switched off, turning it on at the greeter doesn't work. I have to remove the Unifying Receiver and plug it in again while the keyboard is on in order to be able to type.

This strange behaviour was introduced in Precise.

I hope you have enough information at this point. Please feel free to ask for anything else.

bugbot (bugbot) on 2012-05-10
tags: added: kubuntu
vetmode (vetmode) wrote :

Happens to me too, extremely annoying.

Hardware: Logitech K360 Keyboard (Swiss German), Logitech MX Anywhere Mouse, both paired to 1 Unifying Receiver
Software: Ubuntu 12.04 with Swiss German Keyboard locale

Yet the locale I'm typing on seems to be US. Any news on this?

Montblanc (montblanc) wrote :

Nope, still no news unfortunately.

vetmode (vetmode) wrote :

This probably isn't too helpful but I guess it's better than nothing:
I now use an old bluetooth keyboard because the locale then Switches back to normal. Funny enough it even works with the unifying K360 afterwards. Seems like the bluetooth one flips a switch somewhere. Any logs you might want from me with this?

Montblanc (montblanc) wrote :

Your lshal should be fine. :) I hope someone will look into this, someday in the future.

Dirk Porezag (dirk-porezag) wrote :
Download full text (4.9 KiB)

Experienced the same bug after upgrading from 11.0 to 12.04. After some extensive debugging and researching for posts of other people (and distros) with similar problems I think the issue is as follows:

Ubuntu 12.04 comes with Kernel 3.2. 3.2 introduced the logitech_dj HID driver that is supposed to provide full support for the Logitech Unifying Receiver. Kernels < 3.2 used the generic-usb HID driver instead.

With the generic-usb driver, the kernel will create three hidraw device nodes for each unifying receiver: one for the receiver itself, one for a keyboard along with its LED indicators and one that accumulates functions for mice and consumer control devices (for example, the K340 I have has special keys for Mail, Play, on/off, etc. that are similar to a remote control). These functions seem to be contained in the USB HID report descriptor of the Unifying Receiver. Of the three hidraw device nodes, two evdev devices are created under /dev/input, one for keyboard/LED and one for mouse/consumer control and all is working well.

With the logitech-dj driver, the kernel will create one hidraw device node for the receiver itself and one device node for every physical device paired with this receiver. The input properties for each device node are derived from a set of bits that the physical device reports to the Unifying Receiver. Most keyboards I've seen happen to send at least: keyboard + LED, consumer control and system control (there is a power button function on the keyboard, too). So we have one hidraw device node (and a corresponding evdev device node under /dev/input) with keyboard, LED, consumer control and system control capabilities. Unfortunately, the consumer control part contains a key that is translated into a "HorizontalWheel" function.

Now Xorg comes into play. It uses the evdev input devices. With the generic-usb driver, it finds a keyboard and a pointer input device and attributes them to the Virtual core keyboard and Virtual core pointer, respectively, and all is fine. With the logitech-dj driver, it just finds a single input device for the keyboard (and its extra functions like consumer control) and sees that it supposedly has keyboard AND pointer functions (recall the "HorizontalWheel" issue). Based on this, Xorg seems to attribute the device to the Virtual core pointer and leaves the Virtual core keyboard without a physical device. And now it seems that Xorg ignores the keyboard layout settings configured in e.g. /etc/X11/xorg.conf.d/10-keyboard.conf if the only keyboard present is attached to the Virtual Core pointer. There is a bug report that describes this issue at https://bugs.freedesktop.org/show_bug.cgi?id=49950.

So, in short, the logitech_dj driver triggers a bug in Xorg that causes the issue.

I have tried to different fixes to resolve the issue, that both work. Both fixes are workarounds that prevent the Xorg bug to be triggered as long as it exists.

Option 1:
Get the kernel source of your current "precise" kernel and apply the following trivial fix (which is actually a backport from Linux upstream 3.4):
#------------------------
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1463,8 +1463,10 @@...

Read more...

Montblanc (montblanc) wrote :

Kudos, Dirk! :)

I'm so glad that someone could finally solve the mystery behind this issue!

You explained it in a very simple and clear way and provided not 1, but 2 workarounds and also proposed a solution! I'm going for Option 1, but I'm confident they'll remove the logitech-dj driver in the future, that would make sense.

You've become my personal god of bugs, really... thanks!

Michael Sotnikov (stari4ek) wrote :

Have this issue with K400 keyboard (russian)

Sommartel (sommartel) wrote :

Same bug with an other logitech unify keyboard (k400) and Ubuntu 12.04 for keybord swiss-french

A way to circumvemt this bug - at least for the login screen when using LightDM - is to add:
display-setup-script=setxkbmap <layout> <variant>
In /etc/lightdm/lightdm.conf, add

Laurent Simon (stratic) wrote :

Thanks for your advice Cédric. It works like a charm, I was able to type my password using my K800 keyboard.

Stephan Diestelhorst (syon) wrote :

Is the underlzing issue, namely relying on HAL the same as #995380?

Probably but I'm not sure 'caus without xorg.conf keyboard map is wrong
too. Currently I workarounded it with a 'display-setup-script=setxkbmap
fr' in the lightdm.conf file.

 Regards
 Bruno.

Le 26/01/2013 13:01, Stephan Diestelhorst a écrit :
> Is the underlzing issue, namely relying on HAL the same as #995380?
>

--

Bruno MACADRE
-------------------------------------------------------------------
  Ingénieur Systèmes et Réseau | Systems and Network Engineer
  Département Informatique | Department of computer science
  Responsable Réseau et Téléphonie | Telecom and Network Manager
  Université de Rouen | University of Rouen
-------------------------------------------------------------------
Coordonnées / Contact :
 Université de Rouen
 Faculté des Sciences et Techniques - Madrillet
 Avenue de l'Université - BP12
 76801 St Etienne du Rouvray CEDEX
 FRANCE

 Tél : +33 (0)2-32-95-51-86
 Fax : +33 (0)2-32-95-51-87
-------------------------------------------------------------------

This bug was reported in 2012 - and is still present in Kubuntu 14.04.
How can we help to fix this?
Writing the console in the lightdm.conf is no real fix.
Why is it not possible to switch keyboard layouts according to users preferences after the user has entered hi username (or clicked on his user picture?)
The keyboard layout should not be tied to a computer (=lightdm.conf), but user specific: There could be a computer that is used by many different users, all having their own layout ("semi-public" computer, shared in a library or student's home with different people having their own account, sharing the same keyboard...)
So why not let lightdm (who IMHO is in charge of setting the layout then) decide after selecting the user which layout should be chosen? It could be done like in Unity-greeter: the greeter looks up the user desktop picture and displays it in the moment the user is selected. This must be cached in a central place anyway because the user partition could be encrypted. But that is solved in unity-greeter as well.

Montblanc (montblanc) wrote :

Once upon a time, Launchpad was really open. You could set importance, affected releases and assing bugs to people, teams or even yourself. I'm not wondering why I opened this bug more than 2 years ago and no one has taken care of it yet. Probably no one ever will.

Luckily this bug is not a blocker and there are many workarounds. I guess we just have to change our password (as I did) or use Cédric's workaround in comment #23.

Philipp (pe-es-6) wrote :

Just installed a fresh 15.04 and was surprised that this bug is still there... However, for the ones who wrote "setxkbmap de" to /etc/kde4/kdm/Xsetup it's /usr/share/sddm/scripts/Xsetup now... (for the new sddm which replaces kdm).

Jarno Suni (jarnos) wrote :

In my experience, a keyboard using Logitech Unified Receiver (k400) uses different locale than the other (USB) keyboard during the login at LightDM, even if both are connected before and during booting. After login they begin using the same locale. (Mythbuntu 14.04 here)

Jarno Suni (jarnos) wrote :

Christian González, why would you use different layouts for the same keyboard?

Jarno Suni (jarnos) wrote :

Changing language in the language selector in greeter does not change the keyboard accordingly.

Jarno Suni (jarnos) wrote :

Though, changing keyboard together with language might not be always wanted. E.g. you may want to use Finnish keyboard layout (for such keyboard) even if you use English as UI language.

Jarno Suni (jarnos) wrote :

For me connecting the Unifying Receiver only after the greeter is displayed does not work in LightDM (Mythbuntu 14.04) Besides, I suppose having the Unifying Receiver connected while upgrading OS does not affect the bug. The bug exist in (ubuntu) 14.04 with which I started to use the Unifying Receiver.

Jarno Suni (jarnos) on 2015-10-20
summary: - X defaulting keyboard locale to US at login after upgrading distribution
- if a Logitech Unifying Receiver is plugged in
+ X defaulting keyboard locale to US at login by a keyboard paired with
+ Logitech Unifying Receiver
Jarno Suni (jarnos) on 2016-02-01
description: updated
Jarno Suni (jarnos) wrote :

Oh, after editing /etc/lightdm/lightdm.conf like told in comment #23, I was unable to get login screen after boot in Xubuntu 15.10. At least I got login screen after I removed the (otherwise nonexisting) file.

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

Other bug subscribers

Related questions

Remote bug watches

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