<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - USB and DMI keyboard mappings behave differently" href="https://bugs.freedesktop.org/show_bug.cgi?id=78408#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - USB and DMI keyboard mappings behave differently" href="https://bugs.freedesktop.org/show_bug.cgi?id=78408">bug 78408</a> from <a class="email" href="mailto:ed.678901@gmail.com" title="ed.678901@gmail.com">ed.678901@gmail.com</a> <pre>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 <<a href="mailto:ed.678901@gmail.com">ed.678901@gmail.com</a>> 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, <<a href="mailto:bugzilla-daemon@freedesktop.org">bugzilla-daemon@freedesktop.org</a>> wrote: > >> *<a href="show_bug.cgi?id=78408#c6">Comment # 6</a> <<a class="bz_bug_link bz_status_NEW " title="NEW --- - USB and DMI keyboard mappings behave differently" href="show_bug.cgi?id=78408#c6">https://bugs.freedesktop.org/show_bug.cgi?id=78408#c6</a>> >> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - USB and DMI keyboard mappings behave differently" href="show_bug.cgi?id=78408">bug 78408</a> <<a class="bz_bug_link bz_status_NEW " title="NEW --- - USB and DMI keyboard mappings behave differently" href="show_bug.cgi?id=78408">https://bugs.freedesktop.org/show_bug.cgi?id=78408</a>> from >> David Herrmann <<a href="mailto:dh.herrmann@gmail.com">dh.herrmann@gmail.com</a>> * >> >> 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. >> >> ></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>