[libinput] A query regaring key remap functionality

[Peter Hutterer]

On Tue, Dec 22, 2015 at 06:28:21AM +0900, Sung-Jin Park wrote:
> 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?

mapping a device to a left-handed configuration requires some
device-specific knowledge. on a mouse you can just reverse the LMR buttons,
on a touchpad a left-handed software button configuration means different
button events for tapping, clickfinger and software buttons. 

In X, if you apply a left-handed setting to the core pointer (e.g. with
xmodmap), a single-finger tap on a touchpad would produce a right click. See
http://who-t.blogspot.com.au/2009/06/button-mapping-in-x.html for details.

On a tablet, you need to flip some axes and invert the rotation for other
axes, and (on some tablets) rearrange the button order.

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

I'm not sure if that was part of your question, but since it's copied here I
assume it is.

"remapping" is a very ambiguous term. The simplest case is "key A 
should produce keycode B because the hardware is broken". That's what udev's
hwdb is for and it would apply generically to all userspace.

The next case is "Key A should produce keycode B, because I want to". This
is opening a pandora's box, quickly a simple remap isn't sufficient and
you'll need "key A should produce keycode B and then C", followed by "key A
should produce keycode B, wait X ms, then C", followed by "holding a
modifier down would be nice". we have something like this in the wacom
driver to emulate key sequences and it's not ideal. we're trying to API-ify
this for libratbag and it's not pretty, so I'd rather avoid this in
libinput.
But since this is hw-independent you could make this a library separate from
libinput and get the compositor to call it for whatever comes out of
libinput.

The next step is "key A should produce keysym B", and from then on we're
plainly in the keyboard layout territory. That's handled by libxkbcommon and
xkeyboard-config and too client-specific to put into libinput. The only
exception here are hardware devices that produce a real "a" rather than just
KEY_A (e.g. braille devices). So far we haven't had any of those devices to
deal with, so they're on the backburner until the demand shows up.

Cheers,
   Peter


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