[libinput] A query regaring key remap functionality

[Sung-Jin Park]

dh and peter,
thank you for your answer.
Actually I'm trying understand but frankly to say, I don't get the
following comments. And I don't understand why libinput has the left handed
facility as a device configuration. Can you give me more comments on my
doubts?

>keymapping is a lot more complex than a simple A:B remap, before too long
you need application-specific key sequences with timing and potential
pointer state changes. That cannot be solved in libinput, simply because
maintaining a stable API for this is a nightmare.
2015. 12. 21. 오후 4:43에 "Christopher Michael" <cpmichael at osg.samsung.com>님이
작성:

> Peter,
>
> First, Thanks for taking the time to provide input (no pun intended) here
> :) (all else inlined)
>
> On 12/21/2015 02:29 AM, Peter Hutterer wrote:
>
>> On Mon, Dec 21, 2015 at 12:27:08AM -0500, Chris Michael wrote:
>>
>>> On 12/18/2015 01:20 AM, 박성진 wrote:
>>>
>>>> Dear all,
>>>>
>>>> I have a query regarding key remap functionality.
>>>>
>>>> As of now, there is no key remap functionality provided by libinput.
>>>>
>>>>
>>> Personally, if libinput is going to "handle input" .. then it SHOULD be
>>> handling (or at least providing) API for "users" where keymap/keys are
>>> changable ...
>>>
>>> Not sure of Peter's stand on this, but WHY should toolkits need to invent
>>> their own methods of remapping when Input is supposed to handle INPUT ??
>>> X
>>> is/was able to handle this (perhaps not ideal) system wide (per-se)...
>>>
>>
>> keymapping facilities are not going to be in libinput, short of something
>> that works around specific hardware quirks that cannot be fixed with the
>> udev hwdb.
>>
>> keymapping is a lot more complex than a simple A:B remap, before too long
>> you need application-specific key sequences with timing and potential
>> pointer state changes. That cannot be solved in libinput, simply because
>> maintaining a stable API for this is a nightmare. And anything that
>> libinput
>> won't do (i.e. that specific feature that toolkit XYZ wants), will need to
>> be re-implemented by the toolkit anyway. And now you have two competing
>> implementations, in every toolkit.
>>
>>
> Fair enough. What about (possibly) providing some API so that we can use
> libinput to get "available" keymaps ? Not necessarily that libinput is
> doing any mapping, but perhaps it uses xkb to say "here are the available
> mappings for this keyboard" .. just a thought
>
> I am not saying that libinput should be responsible for searching/set
>>> up/acquire keymaps, etc, etc .. but if Given a keymap (via API ..
>>> libinput_keyboard_keymap_set/get...) then why cannot libinput keep that
>>> mapping ???....
>>>
>>> Maybe I am off-base here .. but input should be handled by input (read:
>>> libinput) (imo)... Would make life easier on (all) toolkit
>>> devs..(kde/gnome/efl) if we had a standard ;)
>>>
>>
>> you don't need libinput to have a standard for keymapping, you only need
>> all the toolkits and desktops to agree on a standard. and if you think
>> that's not going to happen - there's the reason why I won't do keymappings
>> in libinput :)
>>
>
> Understand. My thought was simply "If it's in libinput, and everyone is
> already using it, then bonus" ;)
>
>
>>
>>> Requiring each various toolkit to implement this (seemingly) basic
>>> requirement sounds to me like an invitation for disfunction ...
>>>
>>> especially when libinput is there, already dealing with udev, and already
>>> low-level enough (imo) to provide some "system-wide/agreeable"
>>> solution...
>>>
>>> The "mappings" are (or should be) readily available... Perhaps we could
>>> even
>>> reuse existing DBs/files/X Mappings??...
>>>
>>> I’m thinking of having key remap functionality in libinput as one of the
>>>> existing device configuration features.
>>>>
>>>>
>>> Agree !! This would allow all various Toolkits/DEs to have SomeThing in
>>> common...
>>>
>>> (Actually, I made a patch for libinput already and tested it.)
>>>>
>>>>
>>> Link to Patch ?? Was this patch sent to libinput ML ??
>>>
>>> As we have a specific USB TV tuner remote controller named "au0828 IR
>>>> (Hauppauge HVR950Q)" and
>>>>
>>>> when it's been plugged, a key was making a bad keycode(KEY_EXIT)
>>>> different from its original purpose of keycode (KEY_BACK).
>>>>
>>>>
>>> Well, that COULD be a particular hardware issue ... Not enough Info.
>>> Perhaps
>>> the device was sending the wrong code ??...
>>>
>>
>> this sounds like something that should be fixed with the udev hwdb. look
>> for
>> a file named 60-keyboard.hwdb, I suspect that may get you the result you
>> want.
>>
>> I thought there will be more H/Ws in addition to "au0828 IR (Hauppauge
>>>> HVR950Q)" remote controller and
>>>>
>>>>
>>> Absolutely will be more hardware !!
>>>
>>>
>>> this is why I think the key remap feature can be a part of libinput
>>>> device configurations.
>>>>
>>>>
>>> Agree !! BUT where does libinput get this information ?? Udev MAY provide
>>> SOME config info ...
>>>
>>> but as far as key remapping.... "X" was able to do this via some standard
>>> place to "read" possible remaps ... perhaps we (read: libinput) could
>>> reuse
>>> that database/info ?? (with possible adjustments) ...
>>>
>>
>> huh? what remaps does X do? I'm not aware of any specific remapping other
>> than what XKB provides.
>>
>>
> Not remaps in that sense .. just that there is xkb (x libs, etc) that
> provide "here are available keymaps"...
>
> Again, Thanks for your time wrt reply on this one. Hopefully it gives
> Sung-Jin a direction to go in ;)
>
> Cheers,
>
> dh
>
>
> Cheers,
>>     Peter
>>
>>
>>> Having said all that, if your hardware has a faulty remap then obviously
>>> we
>>> (read: libinput/wl/etc) cannot Accommodate Every piece of HW in
>>> existance...so HW devs will need to make sure that their keys are
>>> "correct"
>>> ...
>>>
>>> I am NOT saying that libinput should be responsible for Every Possible
>>> (Mis)Configuration .. BUT if we can come to some "standard" then
>>> everyone's
>>> life Should be that much easier... (read: KEY_F1 is always key f1)..
>>>
>>> Cheers,
>>> Christopher (devilhorns) Michael
>>>
>>> NB: Sent from my personal email and does not reflect any "official"
>>> stance... Just my 2 cents ;)
>>>
>>>
>>> Plz kindly share you guys’ opinion. :D
>>>>
>>>> Thanks,
>>>>
>>>> Sung-Jin Park
>>>>
>>>>
>>>>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151222/78fed0b6/attachment-0001.html>