I was expecting the following two mappings to behave the same way: keyboard:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr* KEYBOARD_KEY_3a=leftctrl keyboard:usb:v*p* KEYBOARD_KEY_70039=leftctrl However, the USB mapping will only work if the existing key is remapped, e.g. keyboard:usb:v*p* KEYBOARD_KEY_70039=leftctrl KEYBOARD_KEY_700e0=capslock It looks like the behaviour for USB keyboards is a bug. I have tested this with systemd-208-16.fc20.x86_64 on kernel versions 3.14.2-200.fc20.x86_64 and 3.11.10-301.fc20.x86_64, as well as with systemd-212-3-x86_64 on 3.14.2-1-ARCH. The hardware I used includes a couple of USB keyboards, an old PS2 keyboard, and the ThinkPad T520 keyboard.
Can you please explain this in some more detail? (In reply to comment #0) > I was expecting the following two mappings to behave the same way: > > keyboard:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr* > KEYBOARD_KEY_3a=leftctrl > > keyboard:usb:v*p* > KEYBOARD_KEY_70039=leftctrl Those would apply to different devices and different keys, so in which sense should they behave the same? > However, the USB mapping will only work if the existing key is remapped, e.g. > > keyboard:usb:v*p* > KEYBOARD_KEY_70039=leftctrl > KEYBOARD_KEY_700e0=capslock > > It looks like the behaviour for USB keyboards is a bug. So what are you trying to do there, and what is the original assignment from the kernel? Do you mean you can't assign multiple scan codes to the same key code for USB devices? Thanks!
Hi Martin, What I mean is that with USB rules, you cannot map a non-modifier key to a modifier key, unless the modifier key in question is also remapped. For example, if you cannot have both Caps Lock and Left Control mapped to the leftctrl keycode at the same time. My expectaction is that you should be able to have the same keycode on a regular key as well as a non-modifier key. The only reason I mentioned DMI rules is because they already satisfy this expectation. For an even more elaborate illustration, could you please see the question I posted on the Unix & Linux StackExchange site? http://unix.stackexchange.com/questions/128234/modifier-keys-cannot-be-mapped-to-regular-keys-on-usb-keyboard-with-udev Let me know if you still don't get what I mean. I can send you the hardware models I used, but I'm confident you will discover the same on any USB keyboard. Ed On 25 May 2014 06:09, <bugzilla-daemon@freedesktop.org> wrote: > Martin Pitt <martin.pitt@ubuntu.com> changed bug 78408<https://bugs.freedesktop.org/show_bug.cgi?id=78408> > What Removed Added Status NEW NEEDINFO > > *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=78408#c1> on > bug 78408 <https://bugs.freedesktop.org/show_bug.cgi?id=78408> from Martin > Pitt <martin.pitt@ubuntu.com> * > > Can you please explain this in some more detail? > > (In reply to comment #0 <https://bugs.freedesktop.org/show_bug.cgi?id=78408#c0>)> I was expecting the following two mappings to behave the same way: > > > > keyboard:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr* > > KEYBOARD_KEY_3a=leftctrl > > > > keyboard:usb:v*p* > > KEYBOARD_KEY_70039=leftctrl > > Those would apply to different devices and different keys, so in which sense > should they behave the same? > > However, the USB mapping will only work if the existing key is remapped, e.g. > > > > keyboard:usb:v*p* > > KEYBOARD_KEY_70039=leftctrl > > KEYBOARD_KEY_700e0=capslock > > > > It looks like the behaviour for USB keyboards is a bug. > > So what are you trying to do there, and what is the original assignment from > the kernel? Do you mean you can't assign multiple scan codes to the same key > code for USB devices? > > Thanks! > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > >
I wrote my reply too quickly: The first paragraph should read "...you cannot map a modifier key to a non-modifier key..." The second paragraph should read "...the same keycode on a regular key as well as a modifier key..." Sorry about the confusion. The link I posted contains a thoroughly proofed explanation. On 26 May 2014 12:20, Ed I <ed.678901@gmail.com> wrote: > Hi Martin, > > What I mean is that with USB rules, you cannot map a non-modifier key to a > modifier key, unless the modifier key in question is also remapped. For > example, if you cannot have both Caps Lock and Left Control mapped to the > leftctrl keycode at the same time. > > My expectaction is that you should be able to have the same keycode on a > regular key as well as a non-modifier key. The only reason I mentioned DMI > rules is because they already satisfy this expectation. > > For an even more elaborate illustration, could you please see the question > I posted on the Unix & Linux StackExchange site? > > > http://unix.stackexchange.com/questions/128234/modifier-keys-cannot-be-mapped-to-regular-keys-on-usb-keyboard-with-udev > > Let me know if you still don't get what I mean. I can send you the > hardware models I used, but I'm confident you will discover the same on any > USB keyboard. > > Ed > > > On 25 May 2014 06:09, <bugzilla-daemon@freedesktop.org> wrote: > >> Martin Pitt <martin.pitt@ubuntu.com> changed bug 78408<https://bugs.freedesktop.org/show_bug.cgi?id=78408> >> What Removed Added Status NEW NEEDINFO >> >> *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=78408#c1> on >> bug 78408 <https://bugs.freedesktop.org/show_bug.cgi?id=78408> from Martin >> Pitt <martin.pitt@ubuntu.com> * >> >> Can you please explain this in some more detail? >> >> (In reply to comment #0 <https://bugs.freedesktop.org/show_bug.cgi?id=78408#c0>)> I was expecting the following two mappings to behave the same way: >> > >> > keyboard:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr* >> > KEYBOARD_KEY_3a=leftctrl >> > >> > keyboard:usb:v*p* >> > KEYBOARD_KEY_70039=leftctrl >> >> Those would apply to different devices and different keys, so in which sense >> should they behave the same? >> > However, the USB mapping will only work if the existing key is remapped, e.g. >> > >> > keyboard:usb:v*p* >> > KEYBOARD_KEY_70039=leftctrl >> > KEYBOARD_KEY_700e0=capslock >> > >> > It looks like the behaviour for USB keyboards is a bug. >> >> So what are you trying to do there, and what is the original assignment from >> the kernel? Do you mean you can't assign multiple scan codes to the same key >> code for USB devices? >> >> Thanks! >> >> ------------------------------ >> You are receiving this mail because: >> >> - You reported the bug. >> >> >
The handling of setkeycode() is subsystem-specific, USB and AT keyboard have different implementations. It is probably and issue or a "feature" of the kernel driver, and nothing udev can do about. http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-input.c#n164
Thanks for the further explanation. Setting back to NEW for now to drop the NEEDSINFO flag. As Kay points out this should probably be fixed in the kernel instead of being worked around in udev keymap.
Can you please describe what you mean by "it's not working"? And please be as specific as possible. Your evtest-log on stackexchange.com shows that the remapping worked _perfectly_. So please let us know what exactly is going wrong. Btw., you're _highly_ advised to _not_ mess with scancode-mappings except for faulty hardware. What you want, is a custom keymap, not a custom scanmap. Therefore, you should modify your XKB keymaps, not the kernel scanmaps. Why, you ask? Because multiple scancodes mapping to the same keycode does not yield the same result as one would expect. The state tracking is still only one bit and done on the _keycode_, not on the _scancode_. This does not happen if you write proper XKB keymaps, which can deal with all that. Btw., there is no difference between modifiers and non-modifiers on the kernel level (or keycode level, or scancode level). The "modifier" concept is introduced by keymaps that XKB provides.
Hi David, When I say "not working" I simply mean there is no indication that the key whose scancode was assigned the keycode was pressed other than the evtest result. Examples: pressing a key with the Shift keycode does not change the case of any character key and holding a key with the Ctrl keycode then pressing 'U' does not erase the command prompt. This is the case whether or not in an X Windows environment. I appreciate the advisory -- I filed this bug report simply because I had taken the time to verify on a few kernel builds and different hardware that this strange behaviour is consistent and also not at all what I had expected, especially since this is not an issue with non-USB keyboards. Also, since all the examples begin to work as expected as soon as the original key from which the scancode belonged to has its keycode remapped to another scancode, I thought the udev team might like to investigate a little so we might have the mapping rules have the principle -- if feasible for you guys. Feel free to try this on any USB keyboard, but I doubt you'll be able to, say, map a new Left Ctrl key while keeping the original one. Isn't it odd to you in principle? If you can verify I'm on the ball or not, I'd be grateful for your time! On 2 June 2014 09:00, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 6 <https://bugs.freedesktop.org/show_bug.cgi?id=78408#c6> on > bug 78408 <https://bugs.freedesktop.org/show_bug.cgi?id=78408> from David > Herrmann <dh.herrmann@gmail.com> * > > Can you please describe what you mean by "it's not working"? And please be as > specific as possible. > > Your evtest-log on stackexchange.com shows that the remapping worked > _perfectly_. So please let us know what exactly is going wrong. > > Btw., you're _highly_ advised to _not_ mess with scancode-mappings except for > faulty hardware. What you want, is a custom keymap, not a custom scanmap. > Therefore, you should modify your XKB keymaps, not the kernel scanmaps. > Why, you ask? Because multiple scancodes mapping to the same keycode does not > yield the same result as one would expect. The state tracking is still only one > bit and done on the _keycode_, not on the _scancode_. This does not happen if > you write proper XKB keymaps, which can deal with all that. > > Btw., there is no difference between modifiers and non-modifiers on the kernel > level (or keycode level, or scancode level). The "modifier" concept is > introduced by keymaps that XKB provides. > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > >
To clarify the second to last sentence in my previous message, I should have said: Map a new Left Ctrl key to a "non-modifier" key while keeping the original one. I was listening when David mentioned that on a level below the keymaps there is no difference between a "modifier" and "non-modifier" key, but using the term makes it more clear to express the inconsistency here, be it something udev can address or not. On 3 June 2014 01:45, Ed I <ed.678901@gmail.com> wrote: > Hi David, > > When I say "not working" I simply mean there is no indication that the key > whose scancode was assigned the keycode was pressed other than the evtest > result. Examples: pressing a key with the Shift keycode does not change the > case of any character key and holding a key with the Ctrl keycode then > pressing 'U' does not erase the command prompt. This is the case whether > or not in an X Windows environment. > > I appreciate the advisory -- I filed this bug report simply because I had > taken the time to verify on a few kernel builds and different hardware that > this strange behaviour is consistent and also not at all what I had > expected, especially since this is not an issue with non-USB keyboards. > > Also, since all the examples begin to work as expected as soon as the > original key from which the scancode belonged to has its keycode remapped > to another scancode, I thought the udev team might like to investigate a > little so we might have the mapping rules have the principle -- if feasible > for you guys. > > Feel free to try this on any USB keyboard, but I doubt you'll be able to, > say, map a new Left Ctrl key while keeping the original one. Isn't it odd > to you in principle? > > If you can verify I'm on the ball or not, I'd be grateful for your time! > > > On 2 June 2014 09:00, <bugzilla-daemon@freedesktop.org> wrote: > >> *Comment # 6 <https://bugs.freedesktop.org/show_bug.cgi?id=78408#c6> >> on bug 78408 <https://bugs.freedesktop.org/show_bug.cgi?id=78408> from >> David Herrmann <dh.herrmann@gmail.com> * >> >> Can you please describe what you mean by "it's not working"? And please be as >> specific as possible. >> >> Your evtest-log on stackexchange.com shows that the remapping worked >> _perfectly_. So please let us know what exactly is going wrong. >> >> Btw., you're _highly_ advised to _not_ mess with scancode-mappings except for >> faulty hardware. What you want, is a custom keymap, not a custom scanmap. >> Therefore, you should modify your XKB keymaps, not the kernel scanmaps. >> Why, you ask? Because multiple scancodes mapping to the same keycode does not >> yield the same result as one would expect. The state tracking is still only one >> bit and done on the _keycode_, not on the _scancode_. This does not happen if >> you write proper XKB keymaps, which can deal with all that. >> >> Btw., there is no difference between modifiers and non-modifiers on the kernel >> level (or keycode level, or scancode level). The "modifier" concept is >> introduced by keymaps that XKB provides. >> >> ------------------------------ >> You are receiving this mail because: >> >> - You reported the bug. >> >> >
(In reply to comment #7) > Also, since all the examples begin to work as expected as soon as the > original key from which the scancode belonged to has its keycode remapped > to another scancode, I thought the udev team might like to investigate a > little so we might have the mapping rules have the principle -- if feasible > for you guys. Actually, that the AT keyboard allows to map two distinct keys to the same code is more a bug in the AT driver than a missing feature of the USB hid driver. Try to press CTRL-left and CAPS LOCK at the same time, then release one of them; now you still have CTRL physically pressed, but nothing will recognize it. What looked "working", just turned into seriously broken now. Udev should not try to support anything like that, it makes no sense; the details are explained in David's comment.
Hi Kay, > Actually, that the AT keyboard allows to map two distinct keys to the > same code is more a bug in the AT driver than a missing feature of the > USB hid driver. That's wonderful to know. Now It doesn't feel odd that you can't have two mappings on the same key with USB keyboards, knowing that AT keyboards are not meant to have it either. > Try to press CTRL-left and CAPS LOCK at the same time, then release one of > them; now you still have CTRL physically pressed, but nothing will recognize > it. What looked "working", just turned into seriously broken now. Thank you very much for this finding. After I try it out I'm going to look for the right place to report this issue. Have a good one!
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.