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