[libinput] A query regaring key remap functionality

[Christopher Michael]

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
>>>
>>>