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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
