[libinput] A query regaring key remap functionality

[Peter Hutterer]

On Mon, Dec 21, 2015 at 02:43:05AM -0500, Christopher Michael wrote:
> 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

you need to define what you think of as "keymap" first. libinput let's you
check whether a device has a specific key. That's not always 100% accurate
because it pretty much uses the HID information of the device and that can
be all over the place (read: often devices advertise more keys than they
have).

other than that, libinput doesn't do anything with it.

 
> >>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" ;)

I know, it's a simple mistake to make and one I've made myself a few times
(and almost codified it :)
libinput is just for input features that are well defined, well established
and used in virtually the same way regardless of the desktop environment.
 
> >>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"...

most of that is provided by xkeyboard-config. the XKB RMLVO and Kcgst format
is a bit clunky and I don't want to handle that in libinput since it's a
very client-specific thing - you may have more than one layout at a time on
any given device, and it's not hw-specific anyway.

Cheers,
   Peter

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