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