[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 #8 from ed.678901 at gmail.com ---
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 at 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 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/710ada36/attachment.html>