[libinput] A query regaring key remap functionality

[Peter Hutterer]

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.

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

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

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
> >
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>