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? >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. <div class="gmail_quote">2015. 12. 21. 오후 4:43에 "Christopher Michael" <<a href="mailto:cpmichael@osg.samsung.com">cpmichael@osg.samsung.com</a>>님이 작성: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Mon, Dec 21, 2015 at 12:27:08AM -0500, Chris Michael wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 12/18/2015 01:20 AM, 박성진 wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Dear all, I have a query regarding key remap functionality. As of now, there is no key remap functionality provided by libinput. </blockquote> 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)... </blockquote> 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. </blockquote> 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 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 ;) </blockquote> 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 :) </blockquote> Understand. My thought was simply "If it's in libinput, and everyone is already using it, then bonus" ;) <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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??... <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I’m thinking of having key remap functionality in libinput as one of the existing device configuration features. </blockquote> Agree !! This would allow all various Toolkits/DEs to have SomeThing in common... <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (Actually, I made a patch for libinput already and tested it.) </blockquote> Link to Patch ?? Was this patch sent to libinput ML ?? <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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). </blockquote> Well, that COULD be a particular hardware issue ... Not enough Info. Perhaps the device was sending the wrong code ??... </blockquote> 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. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I thought there will be more H/Ws in addition to "au0828 IR (Hauppauge HVR950Q)" remote controller and </blockquote> Absolutely will be more hardware !! <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> this is why I think the key remap feature can be a part of libinput device configurations. </blockquote> 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) ... </blockquote> huh? what remaps does X do? I'm not aware of any specific remapping other than what XKB provides. </blockquote> 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 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Cheers, Peter <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 ;) <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Plz kindly share you guys’ opinion. :D Thanks, Sung-Jin Park </blockquote></blockquote></blockquote> _______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote></div>