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