Hi Hans On Tue, Apr 16, 2024, at 4:33 AM, Hans de Goede wrote: > Hi Mark, > > On 4/16/24 1:57 AM, Mark Pearson wrote: >> Hi Dmitry, >> >> On Mon, Apr 15, 2024, at 6:54 PM, Dmitry Torokhov wrote: >>> On Mon, Apr 15, 2024 at 04:28:19PM -0400, Mark Pearson wrote: >>>> Hi >>>> >>>> On Mon, Apr 15, 2024, at 3:58 PM, Dmitry Torokhov wrote: >>>>> On Mon, Apr 15, 2024 at 09:50:37PM +0200, Hans de Goede wrote: >>>>>> Hi, >>>>>> >>>>>> On 4/15/24 9:40 PM, Dmitry Torokhov wrote: >>>>>>> On Wed, Apr 10, 2024 at 10:48:10PM -0400, Mark Pearson wrote: >>>>>>>> >>>>>>>> I have a stronger preference to keep the KEY_DOUBLECLICK - that one seems less controversial as a genuine new input event. >>>>>>> >>>>>>> Please see my response to Peter's letter. I think it very much depends >>>>>>> on how it will be used (associated with the pointer or standalone as it >>>>>>> is now). >>>>>>> >>>>>>> For standalone application, recalling your statement that on Win you >>>>>>> have this gesture invoke configuration utility I would argue for >>>>>>> KEY_CONFIG for it. >>>>>> >>>>>> KEY_CONFIG is already generated by Fn + F# on some ThinkPads to launch >>>>>> the GNOME/KDE control center/panel and I believe that at least GNOME >>>>>> comes with a default binding to map KEY_CONFIG to the control-center. >>>>> >>>>> Not KEY_CONTROLPANEL? >>>>> >>>>> Are there devices that use both Fn+# and the doubleclick? Would it be an >>>>> acceptable behavior for the users to have them behave the same? >>>>> >>>> Catching up with the thread, thanks for all the comments. >>>> >>>> For FN+N (originally KEY_DEBUG_SYS_INFO) the proposal was to now use >>>> KEY_VENDOR there. My conclusion was that this is targeting vendor >>>> specific functionality, and that was the closest fit, if a new keycode >>>> was not preferred. >>> >>> Fn+N -> KEY_VENDOR mapping sounds good to me. >>> >>>> >>>> For the doubletap (which is a unique input event - not related to the >>>> pointer) I would like to keep it as a new unique event. >>>> >>>> I think it's most likely use would be for control panel, but I don't >>>> think it should be limited to that. I can see it being useful if users >>>> are able to reconfigure it to launch something different (browser or >>>> music player maybe?), hence it would be best if it did not conflict >>>> with an existing keycode function. I also can't confirm it doesn't >>>> clash on existing or future systems - it's possible. >>> >>> So here is the problem. Keycodes in linux input are not mere >>> placeholders for something that will be decided later how it is to be >>> used, they are supposed to communicate intent and userspace ideally does >>> not need to have any additional knowledge about where the event is >>> coming from. A keyboard either internal or external sends KEY_SCREENLOCK >>> and the system should lock the screen. It should not be aware that one >>> device was a generic USB external keyboard while another had an internal >>> sensor that recognized hovering palm making swiping motion to the right >>> because a vendor decided to make it. Otherwise you have millions of >>> input devices all generating unique codes and you need userspace to >>> decide how to interpret data coming from each device individually. >>> >>> If you truly do not have a defined use case for it you have a couple >>> options: >>> >>> - assign it KEY_RESERVED, ensure your driver allows remapping to an >>> arbitrary keycode, let user or distro assign desired keycode to it >>> >>> - assign KEY_PROG1 .. KEY_PROG4 - pretty much the same - leave it in the >>> hand of the user to define a shortcut in their DE to make it useful >>> >>>> >>>> FWIW - I wouldn't be surprised with some of the new gaming systems >>>> we're seeing (Steamdeck, Legion-Go, etc), that a doubletap event on a >>>> joystick might be useful to have, if the HW supports it? >>> >>> What would it do exactly? Once we have this answer we can define key or >>> button code (although I do agree that game controller buttons are >>> different from "normal" keys because they map to the geometry of the >>> controller which in turn defines their commonly understood function). >>> >>> But in any case you would not reuse the same keycode for something that >>> is supposed to invoke a configuration utility and also to let's say >>> drop a flash grenade in a game. >>> >> >> Understood. >> >> I don't see a path forward within your stated parameters. I did not realise that there were such limitations, so my apologies for wasting everybody's time, and thank you for your patience and guidance. >> >> I will drop this patch from the series and proceed using existing defined codes only. >> >> Hans, I'll need to rejig things a bits but I have some ideas and I think I can make it work and stay within the pdx86 tree, which will make it simpler. > > Ok this sounds good to me. For Fn + N using KEY_VENDOR sounds good for > me and for the doubletap any one of > KEY_CONFIG/KEY_CONTROLPANEL/KEY_INFO/KEY_PROG1 > or some other suitable KEY_foo define works for me. > I think this should be a configurable input, by design. So my preference (if not allowed a new keycode, which I personally think is the better option) is for PROG1. I discussed with Peter last night and it looks likely OK on their side. I do plan on doing some testing first, so it might take a few days to get the next set of patches out. Mark _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
