On Tue, Dec 22, 2015 at 06:28:21AM +0900, Sung-Jin Park wrote: > 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?
mapping a device to a left-handed configuration requires some device-specific knowledge. on a mouse you can just reverse the LMR buttons, on a touchpad a left-handed software button configuration means different button events for tapping, clickfinger and software buttons. In X, if you apply a left-handed setting to the core pointer (e.g. with xmodmap), a single-finger tap on a touchpad would produce a right click. See http://who-t.blogspot.com.au/2009/06/button-mapping-in-x.html for details. On a tablet, you need to flip some axes and invert the rotation for other axes, and (on some tablets) rearrange the button order. > >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. I'm not sure if that was part of your question, but since it's copied here I assume it is. "remapping" is a very ambiguous term. The simplest case is "key A should produce keycode B because the hardware is broken". That's what udev's hwdb is for and it would apply generically to all userspace. The next case is "Key A should produce keycode B, because I want to". This is opening a pandora's box, quickly a simple remap isn't sufficient and you'll need "key A should produce keycode B and then C", followed by "key A should produce keycode B, wait X ms, then C", followed by "holding a modifier down would be nice". we have something like this in the wacom driver to emulate key sequences and it's not ideal. we're trying to API-ify this for libratbag and it's not pretty, so I'd rather avoid this in libinput. But since this is hw-independent you could make this a library separate from libinput and get the compositor to call it for whatever comes out of libinput. The next step is "key A should produce keysym B", and from then on we're plainly in the keyboard layout territory. That's handled by libxkbcommon and xkeyboard-config and too client-specific to put into libinput. The only exception here are hardware devices that produce a real "a" rather than just KEY_A (e.g. braille devices). So far we haven't had any of those devices to deal with, so they're on the backburner until the demand shows up. Cheers, Peter > 2015. 12. 21. 오후 4:43에 "Christopher Michael" <[email protected]>님이 > 작성: > > > 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
