[systemd-bugs] [Bug 78408] USB and DMI keyboard mappings behave differently

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=78408

--- Comment #7 from ed.678901 at gmail.com ---
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 at 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 at 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.
>
>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140603/8cf924ed/attachment.html>