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.
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.
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.
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.
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à ....
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.
Hi I experience exactly the same behaviour as in Comment 4. I wonder if there is any activity going on around this problem. Thanks,
(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.
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.
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.
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.
Created attachment 95117 [details] [review] Patch xorg-server event to support combo-keyboards Tested on 1.15.0 and 1.14.3
Thanks, the patch fixes the issue with Logitech K270 for me on 1.15.1.
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
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...
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?
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.
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.
(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.
Hi, I have the seem problem. I am on archlinux too. How had you applied the patch on the archlinux package ?
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.
for unifying receiver devices: is this still an issue on kernels 3.19 and later?
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
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?
(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
can I have an evemu-describe for one of these devices please? Of all event nodes, so I can recreate the setup here. Thanks
Created attachment 119492 [details] evemu-describe for Logitech K800
Created attachment 119493 [details] evemu-describe for Logitech Performance MX
Created attachment 119494 [details] evemu-describe for all events on my system
Created attachment 119508 [details] evemu-describe for Logitech K520
Created attachment 119511 [details] evemu-describe for Logitech M310
Created attachment 119512 [details] evemu-describe for all events
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
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".
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.
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.
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.