Bug 49950 - Logitech Unifying Receiver and wrong keyboard layout
Summary: Logitech Unifying Receiver and wrong keyboard layout
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on: 92896 92897
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-15 04:08 UTC by Mathias Anselmann
Modified: 2016-12-12 22:06 UTC (History)
12 users (show)

See Also:
i915 platform:
i915 features:


Attachments
HACK: Handle kbd events at slave pointers (2.79 KB, patch)
2014-03-02 17:06 UTC, Daniel Martin
no flags Details | Splinter Review
Patch xorg-server event to support combo-keyboards (2.07 KB, patch)
2014-03-04 21:19 UTC, Matti Nykyri
no flags Details | Splinter Review
evemu-describe for Logitech K800 (10.63 KB, text/plain)
2015-11-09 07:09 UTC, Niels Ole Salscheider
no flags Details
evemu-describe for Logitech Performance MX (2.28 KB, text/plain)
2015-11-09 07:10 UTC, Niels Ole Salscheider
no flags Details
evemu-describe for all events on my system (3.68 KB, application/octet-stream)
2015-11-09 07:17 UTC, Niels Ole Salscheider
no flags Details
evemu-describe for Logitech K520 (10.59 KB, text/plain)
2015-11-09 13:18 UTC, Mauro Santos
no flags Details
evemu-describe for Logitech M310 (2.22 KB, text/plain)
2015-11-09 13:27 UTC, Mauro Santos
no flags Details
evemu-describe for all events (4.66 KB, text/plain)
2015-11-09 13:28 UTC, Mauro Santos
no flags Details
evemu-describe for custom built keyboard (5.16 KB, text/plain)
2015-11-09 13:56 UTC, Daniel Spannbauer
no flags Details
evemu-describe for "Logitech Unifying Device. Wireless PID:4024" (Logitech K400r) (10.10 KB, text/plain)
2015-11-09 17:37 UTC, Jarno Suni
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mathias Anselmann 2012-05-15 04:08:41 UTC
Hello,
I have a new mouse / keyboard combo an created this 01-keyboard-layout.conf:
https://gist.github.com/2700844

If i start xorg with this configuration, keyboard layout is set fine, according to the log:

[  6964.094] (II) config/udev: Adding input device Logitech Unifying Device. Wireless PID:200a (/dev/input/event1)
[  6964.094] (**) Logitech Unifying Device. Wireless PID:200a: Applying InputClass "Keyboard Defaults"
.
.
.
[  6964.094] (II) XINPUT: Adding extended input device "Logitech Unifying Device. Wireless PID:200a" (type: KEYBOARD, id 9)
[  6964.094] (**) Option "xkb_rules" "evdev"
[  6964.094] (**) Option "xkb_model" "evdev"
[  6964.094] (**) Option "xkb_layout" "de"
[  6964.094] (**) Option "xkb_variant" "nodeadkeys"

Full log is posted here:
http://sprunge.us/PCNb

My output of "setxkbmap -print -verbose 10" also suggests that keyboard layout is set correctly:
https://gist.github.com/2700575

Nevertheless the keyboard layout is still plain English, not German.
If I run "setxkbmap -layout de" the new output of "setxkbmap -print -verbose 10" is:
https://gist.github.com/2700555
(so more or less as before, except the deadkeys is missing) and this time this output is true, I have now a plain German keyboard layout.

So It seems to me as if my settings aren't applied or overwritten.

I use arch linux, with kernel 3.3.6 and xorg-server 1.12.1, also module "hid_logitech_dj" is loaded.
Comment 1 Daniel Stone 2012-05-15 04:15:05 UTC
Does this also happen if you have a completely bare session, e.g. just an xterm running in the server with no window manager? You can start this with:
sudo Xorg :0 -ac -terminate & (sleep 4 && DISPLAY=:0.0 xterm)

Many desktop environments overwrite your server-configured keyboard settings with their own.
Comment 2 Mathias Anselmann 2012-05-15 04:22:48 UTC
Daniel: Yes this happens also in a bare session as you proposed:
sudo Xorg :0 -ac -terminate & (sleep 4 && DISPLAY=:0.0 xterm)

I even don't use a DE (just awesome 4.11). I alos forgot to mention that the keyboard is a K350, if this should matter.
Comment 3 Mathias Anselmann 2012-05-15 10:37:08 UTC
And another addition:
Just installed lts kernel (3.0.31) and surprisingly with this everything works as expected, settings are correctly set.
Here is my complete xorg.log with the LTS kernel:
http://sprunge.us/HUVN

The interesting thing is that this kernel didn't have the "hid_logitech_dj" module, so it might be that the problems are related to it.
Nevertheless compiling a kernel without the module results in both - mouse and keyboard - being unusable, not just in xorg, but even on TTYs. So this module is nowadays mandatory to get this unifying receiver things to work.

I don't know whether the problems are now kernel or xorg related.
Comment 4 Mathieu Bérard 2012-06-18 10:18:28 UTC
Hello, 
I think that bug #46008 is a duplicate of this one.

I am also affected by the same problem. It's a nasty bug from a user experience point of view: not applying the expected keyboard layout results in user password being rejected in the display manager without any obvious sign that the keyboard layout is wrong.

I have done some investigations.
The bug surfaced with linux 3.2, possibly with kernel commit 534a7b8e1.
It changes the way Logitech Unifying devices are treated. Those are wireless Keyboards, Mouses and also Keyboard+Touchpad combo that share a common USB to radio dongle (a so called "Unifying Receiver").
Since that time wireless keyboards paired to a Logitech Unifying USB Receiver is attached to the "Virtual core pointer" and not to the "Virtual core keyboard" as shown in the description of bug #46008. That's because the kernel HID driver now reports all kinds of relatives axes and buttons for those keyboards that may not physically exist.

But the most interesting part is that xorg seems to apply the XKB configuration upon the first keypress from a device *attached to the VCK*.

I have come to this conclusion by doing this experiment step by step:

1- Start xorg with both:
  a) A wireless Logitech Keyboard and a wireless Logitech mouse, both paired to a Unifying USB Receiver. They both get attached to the VCP.
  b) And any "regular" Keyboard plugged. It gets attached to the VCK.

2- Press keys on the Wireless Logitech Keyboard: XKB settings are not properly applied (obvious here with an AZERTY keyboard).

4- Press keys (even just a *single* keypress will work here) on the regular USB Keyboard. XKB settings are applied.

5- Press keys on the Wireless Logitech Keyboard. XKB settings are applied.

It seems that as soon as a key press event is received from a device attached to the VCK, the XKB layout settings are taken into account. With just the Logitech Unifying Keyboard present, there is never happens as the only keyboard present is attached to the VCP.

I think that, apart form the question of determining whether a device is a keyboard or a pointer (xserver's IsPointerDevice() and IsKeyboardDevice() in dix/events.c ? How about xf86-input-evdev's EvdevProbe() setting pInfo->type_name ? I'm quite lost in the code actually), the bug is that XKB setting have to be applied upon the first keypress, whether or not it comes from a device attached to the VCK or the VCP. I have not found where this is supposed to happen in xserver's code...

Voilà ....
Comment 5 Mathieu Bérard 2012-06-18 11:08:50 UTC
fdo bug #24975 and bug #27241 are also duplicates of this one, just with different hardware device.
But the underlying bug is the same: wrong XKB layout with keyboards attached to the VCP.
Comment 6 Mario Natiello 2014-01-16 16:55:05 UTC
Hi
I experience exactly the same behaviour as in Comment 4.
I wonder if there is any activity going on around this problem.
Thanks,
Comment 7 Daniel Martin 2014-02-26 23:46:11 UTC
(In reply to comment #6)
> I experience exactly the same behaviour as in Comment 4.
> I wonder if there is any activity going on around this problem.

Yes. I hit the problem myself with a Logitech TK820 and started to dig into it. Now, I've a few patches fixing the issue here. They don't look like the best approach atm. and it's getting late. I'll pimp and send them to xorg-devel for comments tomorrow.

Basically, Mathieu made a good observation in comment #4, which helped a lot to get a starting point. Pressing a key on the "real" keyboard causes a DeviceChangedEvent (reason: SlaveSwitch) in which case the layout gets applied. 

But, for the wireless Logitech keyboard the X-server doesn't walk through the code path as it intermixes the master devices (core pointer and core keyboard) at one point. The result is that a keypress on the wireless Logitech keyboard causes an internal event with the core keyboard as master, whereas the correct attached master is the core pointer (see the `xinput` hierarchy), later the code checks if the master from the event and the master from the device (Logitech kbd) match. They don't, and the X-server drops the events.

That was one of three steps to get it working.
Comment 8 Matti Nykyri 2014-03-02 13:17:20 UTC
I came to the exact same conlusion as you guys after I updated my old bluetooth keyboard to Logitechs unifying driver with a combo touchpad keyboard. I think this is affecting all the people that are having keyboard combos and their kernel driver binds them to a single event device.

Daniel could you please attach your patch to the bug so that I could also try it out? This is an annoing bug that prevents anyone from setting the correct layout for their keyboards using xorg.
Comment 9 Daniel Martin 2014-03-02 17:06:03 UTC
Created attachment 94970 [details] [review]
HACK: Handle kbd events at slave pointers

Sorry, didn't had time to prettify the patch, nor to rethink about a better solution. But, it worked here.
Comment 10 Matti Nykyri 2014-03-04 21:15:06 UTC
Thanks.. This totally works. Good patch. Cleaned it a bit but didn't have time to dig into xorg code and invent a new solution. But work for me.
Comment 11 Matti Nykyri 2014-03-04 21:19:30 UTC
Created attachment 95117 [details] [review]
Patch xorg-server event to support combo-keyboards

Tested on 1.15.0 and 1.14.3
Comment 12 Erbureth 2014-04-27 10:54:10 UTC
Thanks, the patch fixes the issue with Logitech K270 for me on 1.15.1.
Comment 13 Peter Maunder 2014-04-28 08:46:50 UTC
daniel.pavel solaar package for providing support for Logitech Unifying support on Linux. I use it to manage my Swiss French/German K340. I don't know whether this is relevant for your problems....Peter
Comment 14 AKA Salan 2014-08-17 09:55:31 UTC
Thanks @Matti for the patch. It fixes the issue for me on 1.16.0. It would be nice if this patch could be merged upstream...
Comment 15 Erbureth 2014-08-17 10:11:53 UTC
Interestingly, I do not need any patch for 1.16 (using version from Debian Jessie), it just works for me. (Logitech K270 + M705) Can you guys confirm?
Comment 16 AKA Salan 2014-08-17 13:09:28 UTC
It didn't work for me without the patch on 1.16 (Archlinux 3.16.1). That's why I had to re-build xorg-server with Matti's patch.
Comment 17 Carlos Silva 2015-01-21 02:45:04 UTC
OK, just a heads up. I use Arch Linux too, kernel 3.18.2, Xorg 1.16.3 and the problem is still there. I have my keymap set but everytime I start X I need to manually "setxkbmap pt" to make it load the default keymap or it will be in en.
Comment 18 Serge Koksharov 2015-03-27 14:27:37 UTC
(In reply to Matti Nykyri from comment #11)
> Created attachment 95117 [details] [review] [review]
> Patch xorg-server event to support combo-keyboards
> 
> Tested on 1.15.0 and 1.14.3

Thanks for the patch, now switching of keyboard layout works correctly for my A4TECH wireless keyboard/mouse combo. I have following configuration:

ArchLinux x86_64

kernel: 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux

xorg-server 1.17.1-4 (which I patched)

A4TECH GR-152 wireless keyboard & A4TECH G9-730FX wireless mouse

Feel free to request any additional info if you need so.
Comment 19 muf 2015-04-23 13:01:34 UTC
Hi,

I have the seem problem.
I am on archlinux too.
How had you applied the patch on the archlinux package ?
Comment 20 Leszek Lesner 2015-08-25 10:26:52 UTC
I can confirm the problem. 

The Patch in Comment 11 https://bugs.freedesktop.org/show_bug.cgi?id=49950#c11
fixes the issue for our users in Neptune and X-Server 1.17.2 and was applied in our packages. 

Please also apply this patch upstream.
Comment 21 Peter Hutterer 2015-09-01 02:11:06 UTC
for unifying receiver devices: is this still an issue on kernels 3.19 and later?
Comment 22 Mauro Santos 2015-09-25 20:36:29 UTC
I'm still seeing this problem with Xorg 1.17.2 and kernel 4.1.6.

See https://lists.archlinux.org/pipermail/arch-general/2015-August/039743.html
Comment 23 Lauwenmark 2015-10-30 23:22:24 UTC
I also experienced this bug with a Corsair K95 RGB keyboard. The patch suggested above solved the issue. Why isn't it yet included yet in the code base?
Comment 24 Daniel Spannbauer 2015-11-02 16:51:57 UTC
(In reply to Peter Hutterer from comment #21)
> for unifying receiver devices: is this still an issue on kernels 3.19 and
> later?

Same here....Kernel 4.2.4 and xserver 1.17.4

The patch in comment #11 is working, so please get it into upstream...

Regards
Comment 25 Peter Hutterer 2015-11-09 05:25:32 UTC
can I have an evemu-describe for one of these devices please? Of all event nodes, so I can recreate the setup here. Thanks
Comment 26 Niels Ole Salscheider 2015-11-09 07:09:45 UTC
Created attachment 119492 [details]
evemu-describe for Logitech K800
Comment 27 Niels Ole Salscheider 2015-11-09 07:10:16 UTC
Created attachment 119493 [details]
evemu-describe for Logitech Performance MX
Comment 28 Niels Ole Salscheider 2015-11-09 07:17:58 UTC
Created attachment 119494 [details]
evemu-describe for all events on my system
Comment 29 Mauro Santos 2015-11-09 13:18:16 UTC
Created attachment 119508 [details]
evemu-describe for Logitech K520
Comment 30 Mauro Santos 2015-11-09 13:27:14 UTC
Created attachment 119511 [details]
evemu-describe for Logitech M310
Comment 31 Mauro Santos 2015-11-09 13:28:45 UTC
Created attachment 119512 [details]
evemu-describe for all events
Comment 32 Daniel Spannbauer 2015-11-09 13:56:40 UTC
Created attachment 119513 [details]
evemu-describe for custom built keyboard

Here is a evemu-describe for our custom built keyboard.

I think it will work if the logitechs etc. are working, but just to be sure :)

Regards

Daniel
Comment 33 Jarno Suni 2015-11-09 17:37:30 UTC
Created attachment 119518 [details]
evemu-describe for "Logitech Unifying Device. Wireless PID:4024" (Logitech K400r)

The keyboard is K400r, but evemu-describe has this "Logitech Unifying Device. Wireless PID:4024".
Comment 34 Peter Hutterer 2015-11-10 07:52:25 UTC
I stared at this for a while and there is no good solution. It's a design issue with the X server and cannot easily be fixed without breaking other things.

The source of the issue is that the server provides two devices, a master pointer and a master keyboard. All physical ("slave") devices hang off either of those, depending on the device type. The XI2 spec says a device is attached to only one master at a time, that attachment is exposed in the XIQueryDevice request. When we alternate between two devices of the same type, the XIDeviceChangedEvent signals which device is now the one generating events (plus the device classes). That device ID is also exposed as sourceid in every event.

Where it gets tricky now are devices that look like both pointer and keyboard and generate both types of events as well. The server already has a couple of hacks to route the events more-or-less correctly, but a bunch of other things don't work - see this bug report. A solution for this bug would be to have UpdateFromMaster split between pointer and keyboard and partially copy the slave device's classes into the respective master. But now the device is attached to two devices simultaneously, this may break existing clients.
Anyway, doing this correctly is tricky and piling on more hacks will make the code even harder to fix, and tbh. it's a card-house where we don't know what breaks when we change something.

So at this point I think the only useful solution is to change the input drivers (libinput and evdev) to split any such device up into two separate X devices and have the events routed in the driver already. Thus your devices would show up as two devices for one event node, one that is a nice and pure pointer, one that is a pure keyboard. The driver routes the events accordingly, and none of the hacks in the server are even triggered.

I can't think of a technical downside of this (other than the work required), it would clean up the event handling and may fix a couple of other related bugs on the way. There is precedence for this, the wacom driver already initialises multiple X devices for a single event node and does that routing of events.

So yeah, I think this is really the only solution that won't open another can of worms.
Comment 35 Peter Hutterer 2015-11-11 00:48:10 UTC
Depending on whether you're on evdev or the libinput driver, please CC yourself on the new bugs I filed there. For evdev it's Bug 92897, for libinput it's Bug 92896. Any driver-specific updates will be posted on those bugs.
Comment 36 Peter Hutterer 2016-12-12 22:06:59 UTC
Update: the two bugs are now both closed, libinput has been fixed, evdev is a wontfix. So there's no need to keep this bug open.

Since libinput is the glorious future and whatnot, I'm closing this one as fixed, based on Bug 92896


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.