| Message ID | 20240324210817.192033-2-mpearson-lenovo@squebb.ca (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | [1/4] Input: Add trackpoint doubletap and system debug info keycodes | expand |
Hi, On 3/24/24 10:07 PM, Mark Pearson wrote: > Add support for new input events on Lenovo laptops that need exporting to > user space. > > Lenovo trackpoints are adding the ability to generate a doubletap event. > Add a new keycode to allow this to be used by userspace. > > Lenovo support is using FN+N with Windows to collect needed details for > support cases. Add a keycode so that we'll be able to provide similar > support on Linux. > > Suggested-by: Peter Hutterer <peter.hutterer@redhat.com> > > Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca> > Signed-off-by: Nitin Joshi <njoshi1@lenovo.com> > Signed-off-by: Vishnu Sankar <vsankar@lenovo.com> Thanks, patch looks good to me: Reviewed-by: Hans de Goede <hdegoede@redhat.com> Dmitry, can I have your ack for merging this change through the pdx86 tree (since the first driver using these is a pdx86 driver) ? Regards, Hans > --- > include/uapi/linux/input-event-codes.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h > index 03edf2ccdf6c..bd3baca95749 100644 > --- a/include/uapi/linux/input-event-codes.h > +++ b/include/uapi/linux/input-event-codes.h > @@ -686,6 +686,8 @@ > #define KEY_SIDEVU_SONAR 0x287 > #define KEY_NAV_INFO 0x288 > #define KEY_BRIGHTNESS_MENU 0x289 > +#define KEY_DOUBLECLICK 0x28a > +#define KEY_SYS_DEBUG_INFO 0x28b > > /* > * Some keyboards have keys which do not have a defined meaning, these keys
Hi Mark, On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > Add support for new input events on Lenovo laptops that need exporting to > user space. > > Lenovo trackpoints are adding the ability to generate a doubletap event. > Add a new keycode to allow this to be used by userspace. What is the intended meaning of this keycode? How does it differ from the driver sending BTN_LEFT press/release twice? > > Lenovo support is using FN+N with Windows to collect needed details for > support cases. Add a keycode so that we'll be able to provide similar > support on Linux. Is there a userspace consumer for this? Thanks.
Hi Dmitry On Mon, Apr 8, 2024, at 7:31 PM, Dmitry Torokhov wrote: > Hi Mark, > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >> Add support for new input events on Lenovo laptops that need exporting to >> user space. >> >> Lenovo trackpoints are adding the ability to generate a doubletap event. >> Add a new keycode to allow this to be used by userspace. > > What is the intended meaning of this keycode? How does it differ from > the driver sending BTN_LEFT press/release twice? Double tapping on the trackpoint is a unique event - it's not the same as BTN_LEFT twice. The BIOS will send a new ACPI event for it and it's not meant to be the same as mouse button clicks. For example, on Windows this launches a utility that let's you do various configurations on your laptop (some Lenovo specific), but that's not available on Linux (yet). We did want to make it flexible in this implementation so users could use it for whatever was useful to them. >> >> Lenovo support is using FN+N with Windows to collect needed details for >> support cases. Add a keycode so that we'll be able to provide similar >> support on Linux. > > Is there a userspace consumer for this? There isn't yet, though we would like to implement something, and do plan to. We still have to work through the details of the best way to do this, and if it's Lenovo specific, or (probably better) something generic. I don't have as much knowledge on the user-space side development, and my experience is it tends to move a bit slower for getting things implemented. We thought we'd get the framework in, so it's available, and then work with user-space folk to deliver a solution in a suitable manner. Ultimately this is something we'll need in our Linux preloads and the aim is to make it easier for Linux users to get help from our support team (not always the easiest currently). I don't know if other vendors have something similar, but I wouldn't be surprised if this could be re-used in other cases so I hope it's not Lenovo specific. It felt like it would be useful functionality to have :) Mark
On 09/04/2024 09:31, Dmitry Torokhov wrote: > Hi Mark, > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >> Add support for new input events on Lenovo laptops that need exporting to >> user space. >> >> Lenovo trackpoints are adding the ability to generate a doubletap event. >> Add a new keycode to allow this to be used by userspace. > > What is the intended meaning of this keycode? How does it differ from > the driver sending BTN_LEFT press/release twice? >> >> Lenovo support is using FN+N with Windows to collect needed details for >> support cases. Add a keycode so that we'll be able to provide similar >> support on Linux. > > Is there a userspace consumer for this? Funnily enough XKB has had a keysym for this for decades but it's not hooked up anywhere due to the way it's pointer keys accessibility feature was implemented. Theory is that most of userspace just needs to patch the various pieces together for the new evdev code + keysym, it's not really any different to handling a volume key (except this one needs to be assignable). Cheers, Peter
Hi Dmitry, On 4/9/24 2:00 AM, Mark Pearson wrote: > Hi Dmitry > > On Mon, Apr 8, 2024, at 7:31 PM, Dmitry Torokhov wrote: >> Hi Mark, >> >> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >>> Add support for new input events on Lenovo laptops that need exporting to >>> user space. >>> >>> Lenovo trackpoints are adding the ability to generate a doubletap event. >>> Add a new keycode to allow this to be used by userspace. >> >> What is the intended meaning of this keycode? How does it differ from >> the driver sending BTN_LEFT press/release twice? > > Double tapping on the trackpoint is a unique event - it's not the same as BTN_LEFT twice. The BIOS will send a new ACPI event for it and it's not meant to be the same as mouse button clicks. To extend a bit on this, this double-tap event is not reported through the PS/2 trackpoint interface at all. Instead it is reported to the OS by the ACPI hotkey notifier, which is used to report various multi-media hotkeys and things like that, this is handled by the thinkpad_apci driver which sofar only reports key-presses. So there is no BTN_LEFT to report twice and if we add a BTN_LEFT then we end up with an input_device which has a bunch of KEYs + BTN_LEFT but no abs/rel axis which will just confuse userspace. We could add a second input_device which looks like a mouse but only ever reports BTN_LEFT double-clicks I guess, but as Mark said the intention is for this double-tap to work more like a hotkey then a double click. Also note that regular taps on the trackstick do nothing. Clicking the mouse buttons of the stick involves pressing separate physical buttons between the trackpad and the keyboard and those are reported over the same PS/2 port as the relative motion events from the stick. Regards, Hans
On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > On 09/04/2024 09:31, Dmitry Torokhov wrote: > > Hi Mark, > > > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > > > Add support for new input events on Lenovo laptops that need exporting to > > > user space. > > > > > > Lenovo trackpoints are adding the ability to generate a doubletap event. > > > Add a new keycode to allow this to be used by userspace. > > > > What is the intended meaning of this keycode? How does it differ from > > the driver sending BTN_LEFT press/release twice? > > > > > > Lenovo support is using FN+N with Windows to collect needed details for > > > support cases. Add a keycode so that we'll be able to provide similar > > > support on Linux. > > > > Is there a userspace consumer for this? > > Funnily enough XKB has had a keysym for this for decades but it's not > hooked up anywhere due to the way it's pointer keys accessibility > feature was implemented. Theory is that most of userspace just needs > to patch the various pieces together for the new evdev code + keysym, > it's not really any different to handling a volume key (except this > one needs to be assignable). What is the keysym? If we can make them relatable to each other that would be good. Or maybe we could find a matching usage from HID usage tables... Thanks.
On Tue, Apr 09, 2024 at 12:16:04PM +0200, Hans de Goede wrote: > Hi Dmitry, > > On 4/9/24 2:00 AM, Mark Pearson wrote: > > Hi Dmitry > > > > On Mon, Apr 8, 2024, at 7:31 PM, Dmitry Torokhov wrote: > >> Hi Mark, > >> > >> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > >>> Add support for new input events on Lenovo laptops that need exporting to > >>> user space. > >>> > >>> Lenovo trackpoints are adding the ability to generate a doubletap event. > >>> Add a new keycode to allow this to be used by userspace. > >> > >> What is the intended meaning of this keycode? How does it differ from > >> the driver sending BTN_LEFT press/release twice? > > > > Double tapping on the trackpoint is a unique event - it's not the same as BTN_LEFT twice. The BIOS will send a new ACPI event for it and it's not meant to be the same as mouse button clicks. > > To extend a bit on this, this double-tap event is not reported through > the PS/2 trackpoint interface at all. Instead it is reported to > the OS by the ACPI hotkey notifier, which is used to report various > multi-media hotkeys and things like that, this is handled by > the thinkpad_apci driver which sofar only reports key-presses. Ah, I see, so this is just an arbitrary action not connected with the pointer handling in any way. For such actions we typically assign keycodes based on their intended behavior, so instead of KEY_DOUBLECLICK which conveys user gesture but not the intent you should consider using KEY_CONFIG (with is typically mapped to Application Launcher - Consumer Control Configuration in HID spec) or KEY_CONTROLPANEL (Application Launcher - Control Panel). Thanks.
On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: > On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > > On 09/04/2024 09:31, Dmitry Torokhov wrote: > > > Hi Mark, > > > > > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > > > > Add support for new input events on Lenovo laptops that need exporting to > > > > user space. > > > > > > > > Lenovo trackpoints are adding the ability to generate a doubletap event. > > > > Add a new keycode to allow this to be used by userspace. > > > > > > What is the intended meaning of this keycode? How does it differ from > > > the driver sending BTN_LEFT press/release twice? > > > > > > > > Lenovo support is using FN+N with Windows to collect needed details for > > > > support cases. Add a keycode so that we'll be able to provide similar > > > > support on Linux. > > > > > > Is there a userspace consumer for this? > > > > Funnily enough XKB has had a keysym for this for decades but it's not > > hooked up anywhere due to the way it's pointer keys accessibility > > feature was implemented. Theory is that most of userspace just needs > > to patch the various pieces together for the new evdev code + keysym, > > it's not really any different to handling a volume key (except this > > one needs to be assignable). > > What is the keysym? If we can make them relatable to each other that > would be good. Or maybe we could find a matching usage from HID usage > tables... I was looking through the existing codes and I see: #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ We also have KEY_VENDOR used in a few drivers/plafrom/x86, including thinkkpad_acpi.c and I wonder if it would be suitable for this vendor specific debug info collection application (which I honestly doubt will materialize). Thanks.
Hi Dmitry On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: > On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: >> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: >> > On 09/04/2024 09:31, Dmitry Torokhov wrote: >> > > Hi Mark, >> > > >> > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >> > > > Add support for new input events on Lenovo laptops that need exporting to >> > > > user space. >> > > > >> > > > Lenovo trackpoints are adding the ability to generate a doubletap event. >> > > > Add a new keycode to allow this to be used by userspace. >> > > >> > > What is the intended meaning of this keycode? How does it differ from >> > > the driver sending BTN_LEFT press/release twice? >> > > > >> > > > Lenovo support is using FN+N with Windows to collect needed details for >> > > > support cases. Add a keycode so that we'll be able to provide similar >> > > > support on Linux. >> > > >> > > Is there a userspace consumer for this? >> > >> > Funnily enough XKB has had a keysym for this for decades but it's not >> > hooked up anywhere due to the way it's pointer keys accessibility >> > feature was implemented. Theory is that most of userspace just needs >> > to patch the various pieces together for the new evdev code + keysym, >> > it's not really any different to handling a volume key (except this >> > one needs to be assignable). >> >> What is the keysym? If we can make them relatable to each other that >> would be good. Or maybe we could find a matching usage from HID usage >> tables... > > I was looking through the existing codes and I see: > > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > > We also have KEY_VENDOR used in a few drivers/plafrom/x86, including > thinkkpad_acpi.c and I wonder if it would be suitable for this vendor > specific debug info collection application (which I honestly doubt will > materialize). > That's a somewhat disappointing note on your doubts, is that based on anything? Just wondering what we've done to deserve that criticism. That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I personally don't think KEY_CONFIG matches well), but I would be worried about clashing with existing functionality. Peter - do you have any opinion from the user space side of things, or are these likely unused? KEY_VENDOR seems the safer bet to me (but I don't love it). Dmitry - What are the downsides or concerns of introducing a new code? I'd like to evaluate that against the potential to cause conflicts by re-using existing codes. If you feel strongly about it then I'll defer to your judgement, but I'd like to understand better the context. Thanks Mark
On 10/04/2024 11:20, Dmitry Torokhov wrote: > On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: >> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: >>> On 09/04/2024 09:31, Dmitry Torokhov wrote: >>>> Hi Mark, >>>> >>>> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >>>>> Add support for new input events on Lenovo laptops that need exporting to >>>>> user space. >>>>> >>>>> Lenovo trackpoints are adding the ability to generate a doubletap event. >>>>> Add a new keycode to allow this to be used by userspace. >>>> >>>> What is the intended meaning of this keycode? How does it differ from >>>> the driver sending BTN_LEFT press/release twice? >>>>> >>>>> Lenovo support is using FN+N with Windows to collect needed details for >>>>> support cases. Add a keycode so that we'll be able to provide similar >>>>> support on Linux. >>>> >>>> Is there a userspace consumer for this? >>> >>> Funnily enough XKB has had a keysym for this for decades but it's not >>> hooked up anywhere due to the way it's pointer keys accessibility >>> feature was implemented. Theory is that most of userspace just needs >>> to patch the various pieces together for the new evdev code + keysym, >>> it's not really any different to handling a volume key (except this >>> one needs to be assignable). >> >> What is the keysym? If we can make them relatable to each other that >> would be good. Or maybe we could find a matching usage from HID usage >> tables... There's a set of XK_Pointer_ keysyms defined in X11/keysym.h, including XK_Pointer_DblClick1 and XK_Pointer_DblClickDefault. Unfortunately they're not hooked up to anything atm, see this draft MR: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/659 Because they're not hooked up anywhere they'll also need to be hooked into the client space, same as the various XF86FooBar symbols we've added over the years. If we were to add KEY_DOUBLECLICK we can patch xkeyboard-config to bind that to the existing XK_Pointer_DblClickDefault symbol (it would get XF86DoubleClick assigned by the current automated scripts), so in theory that key would work like any other key with that symbol assigned. > I was looking through the existing codes and I see: > > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > > We also have KEY_VENDOR used in a few drivers/plafrom/x86, including > thinkkpad_acpi.c and I wonder if it would be suitable for this vendor > specific debug info collection application (which I honestly doubt will > materialize). fwiw, I suggested KEY_DOUBLECLICK because that is the action the user takes. Whether that starts a particular application is mostly a question of configuration, defaulting to something that emulates a double-click seems prudent though. And if someone wants to remap that to the compose key that'd be trivial too then. Cheers, Peter
On Tue, Apr 09, 2024 at 10:17:05PM -0400, Mark Pearson wrote: > Hi Dmitry > > On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: > > On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: > >> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > >> > On 09/04/2024 09:31, Dmitry Torokhov wrote: > >> > > Hi Mark, > >> > > > >> > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > >> > > > Add support for new input events on Lenovo laptops that need exporting to > >> > > > user space. > >> > > > > >> > > > Lenovo trackpoints are adding the ability to generate a doubletap event. > >> > > > Add a new keycode to allow this to be used by userspace. > >> > > > >> > > What is the intended meaning of this keycode? How does it differ from > >> > > the driver sending BTN_LEFT press/release twice? > >> > > > > >> > > > Lenovo support is using FN+N with Windows to collect needed details for > >> > > > support cases. Add a keycode so that we'll be able to provide similar > >> > > > support on Linux. > >> > > > >> > > Is there a userspace consumer for this? > >> > > >> > Funnily enough XKB has had a keysym for this for decades but it's not > >> > hooked up anywhere due to the way it's pointer keys accessibility > >> > feature was implemented. Theory is that most of userspace just needs > >> > to patch the various pieces together for the new evdev code + keysym, > >> > it's not really any different to handling a volume key (except this > >> > one needs to be assignable). > >> > >> What is the keysym? If we can make them relatable to each other that > >> would be good. Or maybe we could find a matching usage from HID usage > >> tables... > > > > I was looking through the existing codes and I see: > > > > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > > > > We also have KEY_VENDOR used in a few drivers/plafrom/x86, including > > thinkkpad_acpi.c and I wonder if it would be suitable for this vendor > > specific debug info collection application (which I honestly doubt will > > materialize). > > > > That's a somewhat disappointing note on your doubts, is that based on > anything? Just wondering what we've done to deserve that criticism. Sorry, this was not meant as a criticism really, but you mentioned yourself that there isn't anything in the works yet, you just have some plans. For such a project to succeed Lenovo needs to invest into selling devices with Linux as a primary operating system, and it has to be consumer segment (or small business, because for corporate they typically roll their own support channels). The case of retrofitting Linux onto a that device originally came with Windows OS rarely gets much if any response from the normal support channels. Is this something that is actually happening? > > That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I > personally don't think KEY_CONFIG matches well), but I would be > worried about clashing with existing functionality. > > Peter - do you have any opinion from the user space side of things, or > are these likely unused? KEY_VENDOR seems the safer bet to me (but I > don't love it). > > Dmitry - What are the downsides or concerns of introducing a new code? > I'd like to evaluate that against the potential to cause conflicts by > re-using existing codes. If you feel strongly about it then I'll defer > to your judgement, but I'd like to understand better the context. The keycode space is finite and extending bitmaps leads to more memory consumption and weird breakages (like uevent generation exceeding 4K memory page resulting in failures). I am trying to balance need for new keycodes with how likely they are to be used. Thanks.
Hi Dmitry, On Wed, Apr 10, 2024, at 8:02 PM, Dmitry Torokhov wrote: > On Tue, Apr 09, 2024 at 10:17:05PM -0400, Mark Pearson wrote: >> Hi Dmitry >> >> On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: >> > On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: >> >> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: >> >> > On 09/04/2024 09:31, Dmitry Torokhov wrote: >> >> > > Hi Mark, >> >> > > >> >> > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >> >> > > > Add support for new input events on Lenovo laptops that need exporting to >> >> > > > user space. >> >> > > > >> >> > > > Lenovo trackpoints are adding the ability to generate a doubletap event. >> >> > > > Add a new keycode to allow this to be used by userspace. >> >> > > >> >> > > What is the intended meaning of this keycode? How does it differ from >> >> > > the driver sending BTN_LEFT press/release twice? >> >> > > > >> >> > > > Lenovo support is using FN+N with Windows to collect needed details for >> >> > > > support cases. Add a keycode so that we'll be able to provide similar >> >> > > > support on Linux. >> >> > > >> >> > > Is there a userspace consumer for this? >> >> > >> >> > Funnily enough XKB has had a keysym for this for decades but it's not >> >> > hooked up anywhere due to the way it's pointer keys accessibility >> >> > feature was implemented. Theory is that most of userspace just needs >> >> > to patch the various pieces together for the new evdev code + keysym, >> >> > it's not really any different to handling a volume key (except this >> >> > one needs to be assignable). >> >> >> >> What is the keysym? If we can make them relatable to each other that >> >> would be good. Or maybe we could find a matching usage from HID usage >> >> tables... >> > >> > I was looking through the existing codes and I see: >> > >> > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ >> > >> > We also have KEY_VENDOR used in a few drivers/plafrom/x86, including >> > thinkkpad_acpi.c and I wonder if it would be suitable for this vendor >> > specific debug info collection application (which I honestly doubt will >> > materialize). >> > >> >> That's a somewhat disappointing note on your doubts, is that based on >> anything? Just wondering what we've done to deserve that criticism. > > Sorry, this was not meant as a criticism really, but you mentioned > yourself that there isn't anything in the works yet, you just have some > plans. All good - I was just worried we'd promised something previously and not delivered. We're often slow at delivering - but I try not to fail completely. I try especially hard not to annoy hard working kernel maintainers :) We do have something developed internally, but it's pretty basic and we'll need to have discussion with 'userspace' fol as to if we release that as a standalone application, or if we tie into gnome (which we don't have a lot of experience with)...or something else. Kernel world is much easier :) > > For such a project to succeed Lenovo needs to invest into selling > devices with Linux as a primary operating system, and it has to be > consumer segment (or small business, because for corporate they > typically roll their own support channels). The case of retrofitting > Linux onto a that device originally came with Windows OS rarely gets > much if any response from the normal support channels. > > Is this something that is actually happening? This is way off topic for the patch set, but as you asked :) I'm afraid I'm going to disagree. What you're suggesting is probably the more common and easier route vendors take, but it has some issues and I think some longer term limitations. For me one of the things I like the most about our program using the same exact HW as Windows is it means: - I have a business lever to get Linux support from HW vendors. This makes a difference when you're dealing with 'minor' components - panels, fingerprint readers, touchpads etc - the smaller devices (though it helps for the CPU vendors too). We have requirements that state the upstream Linux support is needed or the chip vendor will not be considered for the platform...and that's a big deal. - It gets FW teams thinking about Linux support. Yeah, there are still a ton of issues there and it's far from perfect, but it means they have to think about Linux support and at least helps us shine a bit of light on what is going on in that horrible closed box. - It means I get Linux running at a good level on a wider range of HW then would be otherwise possible. It means that when there is new technology I get to go and ask "how about Linux" and have that discussion (including schedules). It might come later than I'd like - but at least we get to put Linux on the roadmap rather than being excluded for being so niche. Shrug. I think our Linux program still has a long way to go before it's even close to good - but it's in better shape than it (at least I think so, I don't love the way the industry is going with more being stuffed in FW...but that's above my paygrade) > >> >> That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I >> personally don't think KEY_CONFIG matches well), but I would be >> worried about clashing with existing functionality. >> >> Peter - do you have any opinion from the user space side of things, or >> are these likely unused? KEY_VENDOR seems the safer bet to me (but I >> don't love it). >> >> Dmitry - What are the downsides or concerns of introducing a new code? >> I'd like to evaluate that against the potential to cause conflicts by >> re-using existing codes. If you feel strongly about it then I'll defer >> to your judgement, but I'd like to understand better the context. > > The keycode space is finite and extending bitmaps leads to more memory > consumption and weird breakages (like uevent generation exceeding 4K > memory page resulting in failures). I am trying to balance need for new > keycodes with how likely they are to be used. > Ack. So I've been refactoring my patches to implement the feedback from Hans for the latter patches and just need to figure out what works here. For the SYS_DEBUG_INFO, if you'd rather we use KEY_VENDOR (I think that's my preference - as its intended for a Lenovo support role it seems the best fit), and Peter has no objections, I will make that change. I have a stronger preference to keep the KEY_DOUBLECLICK - that one seems less controversial as a genuine new input event. Is that OK? Mark
Hi Dmitry, On 4/11/24 2:02 AM, Dmitry Torokhov wrote: > On Tue, Apr 09, 2024 at 10:17:05PM -0400, Mark Pearson wrote: >> Hi Dmitry >> >> On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: >>> On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: >>>> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: >>>>> On 09/04/2024 09:31, Dmitry Torokhov wrote: >>>>>> Hi Mark, >>>>>> >>>>>> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >>>>>>> Add support for new input events on Lenovo laptops that need exporting to >>>>>>> user space. >>>>>>> >>>>>>> Lenovo trackpoints are adding the ability to generate a doubletap event. >>>>>>> Add a new keycode to allow this to be used by userspace. >>>>>> >>>>>> What is the intended meaning of this keycode? How does it differ from >>>>>> the driver sending BTN_LEFT press/release twice? >>>>>>> >>>>>>> Lenovo support is using FN+N with Windows to collect needed details for >>>>>>> support cases. Add a keycode so that we'll be able to provide similar >>>>>>> support on Linux. >>>>>> >>>>>> Is there a userspace consumer for this? >>>>> >>>>> Funnily enough XKB has had a keysym for this for decades but it's not >>>>> hooked up anywhere due to the way it's pointer keys accessibility >>>>> feature was implemented. Theory is that most of userspace just needs >>>>> to patch the various pieces together for the new evdev code + keysym, >>>>> it's not really any different to handling a volume key (except this >>>>> one needs to be assignable). >>>> >>>> What is the keysym? If we can make them relatable to each other that >>>> would be good. Or maybe we could find a matching usage from HID usage >>>> tables... >>> >>> I was looking through the existing codes and I see: >>> >>> #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ >>> >>> We also have KEY_VENDOR used in a few drivers/plafrom/x86, including >>> thinkkpad_acpi.c and I wonder if it would be suitable for this vendor >>> specific debug info collection application (which I honestly doubt will >>> materialize). >>> >> >> That's a somewhat disappointing note on your doubts, is that based on >> anything? Just wondering what we've done to deserve that criticism. > > Sorry, this was not meant as a criticism really, but you mentioned > yourself that there isn't anything in the works yet, you just have some > plans. > > For such a project to succeed Lenovo needs to invest into selling > devices with Linux as a primary operating system, and it has to be > consumer segment (or small business, because for corporate they > typically roll their own support channels). The case of retrofitting > Linux onto a that device originally came with Windows OS rarely gets > much if any response from the normal support channels. > > Is this something that is actually happening? Yes, Lenovo is actually offering Fedora as an OS choice when ordering ThinkPads directly from their website in many countries including when ordering as a consumer. And unlike other vendor's Linux preloads which often use a kernel with downstream laptop specific changes these laptops are running unmodified Fedora kernels, which themselves are almost pristine upstream kernels. Lenovo (Mark) has been really good the last couple of years in making sure that their hw just works with mainline kernels without any downstream vendor specific patches. >> That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I >> personally don't think KEY_CONFIG matches well), but I would be >> worried about clashing with existing functionality. Using KEY_INFO / KEY_VENDOR works for me too. So maybe we should just go with one of those 2 ? Regards, Hans
On Wed, Apr 10, 2024 at 02:32:56PM +1000, Peter Hutterer wrote: > On 10/04/2024 11:20, Dmitry Torokhov wrote: > > On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: > > > On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > > > > On 09/04/2024 09:31, Dmitry Torokhov wrote: > > > > > Hi Mark, > > > > > > > > > > On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > > > > > > Add support for new input events on Lenovo laptops that need exporting to > > > > > > user space. > > > > > > > > > > > > Lenovo trackpoints are adding the ability to generate a doubletap event. > > > > > > Add a new keycode to allow this to be used by userspace. > > > > > > > > > > What is the intended meaning of this keycode? How does it differ from > > > > > the driver sending BTN_LEFT press/release twice? > > > > > > > > > > > > Lenovo support is using FN+N with Windows to collect needed details for > > > > > > support cases. Add a keycode so that we'll be able to provide similar > > > > > > support on Linux. > > > > > > > > > > Is there a userspace consumer for this? > > > > > > > > Funnily enough XKB has had a keysym for this for decades but it's not > > > > hooked up anywhere due to the way it's pointer keys accessibility > > > > feature was implemented. Theory is that most of userspace just needs > > > > to patch the various pieces together for the new evdev code + keysym, > > > > it's not really any different to handling a volume key (except this > > > > one needs to be assignable). > > > > > > What is the keysym? If we can make them relatable to each other that > > > would be good. Or maybe we could find a matching usage from HID usage > > > tables... > > There's a set of XK_Pointer_ keysyms defined in X11/keysym.h, > including XK_Pointer_DblClick1 and XK_Pointer_DblClickDefault. > Unfortunately they're not hooked up to anything atm, see this draft > MR: > https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/659 > Because they're not hooked up anywhere they'll also need to be hooked > into the client space, same as the various XF86FooBar symbols we've > added over the years. > > If we were to add KEY_DOUBLECLICK we can patch xkeyboard-config to > bind that to the existing XK_Pointer_DblClickDefault symbol (it would > get XF86DoubleClick assigned by the current automated scripts), so in > theory that key would work like any other key with that symbol > assigned. > > > I was looking through the existing codes and I see: > > > > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > > > > We also have KEY_VENDOR used in a few drivers/plafrom/x86, including > > thinkkpad_acpi.c and I wonder if it would be suitable for this vendor > > specific debug info collection application (which I honestly doubt will > > materialize). > > fwiw, I suggested KEY_DOUBLECLICK because that is the action the user > takes. Whether that starts a particular application is mostly a > question of configuration, defaulting to something that emulates a > double-click seems prudent though. And if someone wants to remap that > to the compose key that'd be trivial too then. I think whether to create and use KEY_DOUBLECLICK is very much depends if we associate this with the pointer somehow, or if we keep it as a completely separate action. If we continue with KEY_DOUBLECLICK then we need to try and define what exactly it means to the applications. Actually same goes if we want another new keycode. As far as easy remapping, I think one can map this to KEY_RESERVED and then remap to whatever they want, you do not need to have a new keycode for that. Thanks.
On Thu, Apr 11, 2024 at 02:30:35PM +0200, Hans de Goede wrote: > Hi Dmitry, > > On 4/11/24 2:02 AM, Dmitry Torokhov wrote: > > On Tue, Apr 09, 2024 at 10:17:05PM -0400, Mark Pearson wrote: > >> Hi Dmitry > >> > >> On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: > >>> On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: > >>>> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > >>>>> On 09/04/2024 09:31, Dmitry Torokhov wrote: > >>>>>> Hi Mark, > >>>>>> > >>>>>> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > >>>>>>> Add support for new input events on Lenovo laptops that need exporting to > >>>>>>> user space. > >>>>>>> > >>>>>>> Lenovo trackpoints are adding the ability to generate a doubletap event. > >>>>>>> Add a new keycode to allow this to be used by userspace. > >>>>>> > >>>>>> What is the intended meaning of this keycode? How does it differ from > >>>>>> the driver sending BTN_LEFT press/release twice? > >>>>>>> > >>>>>>> Lenovo support is using FN+N with Windows to collect needed details for > >>>>>>> support cases. Add a keycode so that we'll be able to provide similar > >>>>>>> support on Linux. > >>>>>> > >>>>>> Is there a userspace consumer for this? > >>>>> > >>>>> Funnily enough XKB has had a keysym for this for decades but it's not > >>>>> hooked up anywhere due to the way it's pointer keys accessibility > >>>>> feature was implemented. Theory is that most of userspace just needs > >>>>> to patch the various pieces together for the new evdev code + keysym, > >>>>> it's not really any different to handling a volume key (except this > >>>>> one needs to be assignable). > >>>> > >>>> What is the keysym? If we can make them relatable to each other that > >>>> would be good. Or maybe we could find a matching usage from HID usage > >>>> tables... > >>> > >>> I was looking through the existing codes and I see: > >>> > >>> #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > >>> > >>> We also have KEY_VENDOR used in a few drivers/plafrom/x86, including > >>> thinkkpad_acpi.c and I wonder if it would be suitable for this vendor > >>> specific debug info collection application (which I honestly doubt will > >>> materialize). > >>> > >> > >> That's a somewhat disappointing note on your doubts, is that based on > >> anything? Just wondering what we've done to deserve that criticism. > > > > Sorry, this was not meant as a criticism really, but you mentioned > > yourself that there isn't anything in the works yet, you just have some > > plans. > > > > For such a project to succeed Lenovo needs to invest into selling > > devices with Linux as a primary operating system, and it has to be > > consumer segment (or small business, because for corporate they > > typically roll their own support channels). The case of retrofitting > > Linux onto a that device originally came with Windows OS rarely gets > > much if any response from the normal support channels. > > > > Is this something that is actually happening? > > Yes, Lenovo is actually offering Fedora as an OS choice when > ordering ThinkPads directly from their website in many countries > including when ordering as a consumer. Ah, very nice, I was not aware of this. > > And unlike other vendor's Linux preloads which often use a kernel > with downstream laptop specific changes these laptops are running > unmodified Fedora kernels, which themselves are almost pristine > upstream kernels. > > Lenovo (Mark) has been really good the last couple of years in > making sure that their hw just works with mainline kernels without > any downstream vendor specific patches. > > >> That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I > >> personally don't think KEY_CONFIG matches well), but I would be > >> worried about clashing with existing functionality. > > Using KEY_INFO / KEY_VENDOR works for me too. So maybe we should > just go with one of those 2 ? It looks like Mark's preference is KEY_VENDOR, so let's go with it? Thanks.
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. Thanks.
Hi, On 4/15/24 9:35 PM, Dmitry Torokhov wrote: > On Thu, Apr 11, 2024 at 02:30:35PM +0200, Hans de Goede wrote: >> Hi Dmitry, >> >> On 4/11/24 2:02 AM, Dmitry Torokhov wrote: >>> On Tue, Apr 09, 2024 at 10:17:05PM -0400, Mark Pearson wrote: >>>> Hi Dmitry >>>> >>>> On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: >>>>> On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: >>>>>> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: >>>>>>> On 09/04/2024 09:31, Dmitry Torokhov wrote: >>>>>>>> Hi Mark, >>>>>>>> >>>>>>>> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: >>>>>>>>> Add support for new input events on Lenovo laptops that need exporting to >>>>>>>>> user space. >>>>>>>>> >>>>>>>>> Lenovo trackpoints are adding the ability to generate a doubletap event. >>>>>>>>> Add a new keycode to allow this to be used by userspace. >>>>>>>> >>>>>>>> What is the intended meaning of this keycode? How does it differ from >>>>>>>> the driver sending BTN_LEFT press/release twice? >>>>>>>>> >>>>>>>>> Lenovo support is using FN+N with Windows to collect needed details for >>>>>>>>> support cases. Add a keycode so that we'll be able to provide similar >>>>>>>>> support on Linux. >>>>>>>> >>>>>>>> Is there a userspace consumer for this? >>>>>>> >>>>>>> Funnily enough XKB has had a keysym for this for decades but it's not >>>>>>> hooked up anywhere due to the way it's pointer keys accessibility >>>>>>> feature was implemented. Theory is that most of userspace just needs >>>>>>> to patch the various pieces together for the new evdev code + keysym, >>>>>>> it's not really any different to handling a volume key (except this >>>>>>> one needs to be assignable). >>>>>> >>>>>> What is the keysym? If we can make them relatable to each other that >>>>>> would be good. Or maybe we could find a matching usage from HID usage >>>>>> tables... >>>>> >>>>> I was looking through the existing codes and I see: >>>>> >>>>> #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ >>>>> >>>>> We also have KEY_VENDOR used in a few drivers/plafrom/x86, including >>>>> thinkkpad_acpi.c and I wonder if it would be suitable for this vendor >>>>> specific debug info collection application (which I honestly doubt will >>>>> materialize). >>>>> >>>> >>>> That's a somewhat disappointing note on your doubts, is that based on >>>> anything? Just wondering what we've done to deserve that criticism. >>> >>> Sorry, this was not meant as a criticism really, but you mentioned >>> yourself that there isn't anything in the works yet, you just have some >>> plans. >>> >>> For such a project to succeed Lenovo needs to invest into selling >>> devices with Linux as a primary operating system, and it has to be >>> consumer segment (or small business, because for corporate they >>> typically roll their own support channels). The case of retrofitting >>> Linux onto a that device originally came with Windows OS rarely gets >>> much if any response from the normal support channels. >>> >>> Is this something that is actually happening? >> >> Yes, Lenovo is actually offering Fedora as an OS choice when >> ordering ThinkPads directly from their website in many countries >> including when ordering as a consumer. > > Ah, very nice, I was not aware of this. > >> >> And unlike other vendor's Linux preloads which often use a kernel >> with downstream laptop specific changes these laptops are running >> unmodified Fedora kernels, which themselves are almost pristine >> upstream kernels. >> >> Lenovo (Mark) has been really good the last couple of years in >> making sure that their hw just works with mainline kernels without >> any downstream vendor specific patches. >> >>>> That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I >>>> personally don't think KEY_CONFIG matches well), but I would be >>>> worried about clashing with existing functionality. >> >> Using KEY_INFO / KEY_VENDOR works for me too. So maybe we should >> just go with one of those 2 ? > > It looks like Mark's preference is KEY_VENDOR, so let's go with it? Ack KEY_VENDOR sounds good to me for the doubletap on the trackpoint event. What about the new Fn + N keycombo which also generates a WMI event which we want to translate to a key code to launch a (to be written) debug-info collecting app for when the customer calls Lenovo support. Mark suggested a new KEY_SYS_DEBUG_INFO for that. So do we use: #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ for this, or do we define a new keycode ? Mark would using KEY_INFO for this work for you. Dmitry any opinion on this ? Regards, Hans
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. So IMHO re-using KEY_CONFIG for the doubletap trackpoint thing is not a good idea. But as mentioned elsewhere in the thread everyone seems to be ok with using KEY_VENDOR for this ? Regards, Hans
On Mon, Apr 15, 2024 at 09:47:10PM +0200, Hans de Goede wrote: > Hi, > > On 4/15/24 9:35 PM, Dmitry Torokhov wrote: > > On Thu, Apr 11, 2024 at 02:30:35PM +0200, Hans de Goede wrote: > >> Hi Dmitry, > >> > >> On 4/11/24 2:02 AM, Dmitry Torokhov wrote: > >>> On Tue, Apr 09, 2024 at 10:17:05PM -0400, Mark Pearson wrote: > >>>> Hi Dmitry > >>>> > >>>> On Tue, Apr 9, 2024, at 9:20 PM, Dmitry Torokhov wrote: > >>>>> On Tue, Apr 09, 2024 at 02:47:05PM -0700, Dmitry Torokhov wrote: > >>>>>> On Tue, Apr 09, 2024 at 03:23:52PM +1000, Peter Hutterer wrote: > >>>>>>> On 09/04/2024 09:31, Dmitry Torokhov wrote: > >>>>>>>> Hi Mark, > >>>>>>>> > >>>>>>>> On Sun, Mar 24, 2024 at 05:07:58PM -0400, Mark Pearson wrote: > >>>>>>>>> Add support for new input events on Lenovo laptops that need exporting to > >>>>>>>>> user space. > >>>>>>>>> > >>>>>>>>> Lenovo trackpoints are adding the ability to generate a doubletap event. > >>>>>>>>> Add a new keycode to allow this to be used by userspace. > >>>>>>>> > >>>>>>>> What is the intended meaning of this keycode? How does it differ from > >>>>>>>> the driver sending BTN_LEFT press/release twice? > >>>>>>>>> > >>>>>>>>> Lenovo support is using FN+N with Windows to collect needed details for > >>>>>>>>> support cases. Add a keycode so that we'll be able to provide similar > >>>>>>>>> support on Linux. > >>>>>>>> > >>>>>>>> Is there a userspace consumer for this? > >>>>>>> > >>>>>>> Funnily enough XKB has had a keysym for this for decades but it's not > >>>>>>> hooked up anywhere due to the way it's pointer keys accessibility > >>>>>>> feature was implemented. Theory is that most of userspace just needs > >>>>>>> to patch the various pieces together for the new evdev code + keysym, > >>>>>>> it's not really any different to handling a volume key (except this > >>>>>>> one needs to be assignable). > >>>>>> > >>>>>> What is the keysym? If we can make them relatable to each other that > >>>>>> would be good. Or maybe we could find a matching usage from HID usage > >>>>>> tables... > >>>>> > >>>>> I was looking through the existing codes and I see: > >>>>> > >>>>> #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > >>>>> > >>>>> We also have KEY_VENDOR used in a few drivers/plafrom/x86, including > >>>>> thinkkpad_acpi.c and I wonder if it would be suitable for this vendor > >>>>> specific debug info collection application (which I honestly doubt will > >>>>> materialize). > >>>>> > >>>> > >>>> That's a somewhat disappointing note on your doubts, is that based on > >>>> anything? Just wondering what we've done to deserve that criticism. > >>> > >>> Sorry, this was not meant as a criticism really, but you mentioned > >>> yourself that there isn't anything in the works yet, you just have some > >>> plans. > >>> > >>> For such a project to succeed Lenovo needs to invest into selling > >>> devices with Linux as a primary operating system, and it has to be > >>> consumer segment (or small business, because for corporate they > >>> typically roll their own support channels). The case of retrofitting > >>> Linux onto a that device originally came with Windows OS rarely gets > >>> much if any response from the normal support channels. > >>> > >>> Is this something that is actually happening? > >> > >> Yes, Lenovo is actually offering Fedora as an OS choice when > >> ordering ThinkPads directly from their website in many countries > >> including when ordering as a consumer. > > > > Ah, very nice, I was not aware of this. > > > >> > >> And unlike other vendor's Linux preloads which often use a kernel > >> with downstream laptop specific changes these laptops are running > >> unmodified Fedora kernels, which themselves are almost pristine > >> upstream kernels. > >> > >> Lenovo (Mark) has been really good the last couple of years in > >> making sure that their hw just works with mainline kernels without > >> any downstream vendor specific patches. > >> > >>>> That aside, I guess KEY_INFO or KEY_VENDOR could be a good fit (I > >>>> personally don't think KEY_CONFIG matches well), but I would be > >>>> worried about clashing with existing functionality. > >> > >> Using KEY_INFO / KEY_VENDOR works for me too. So maybe we should > >> just go with one of those 2 ? > > > > It looks like Mark's preference is KEY_VENDOR, so let's go with it? > > Ack KEY_VENDOR sounds good to me for the doubletap on the trackpoint event. > > What about the new Fn + N keycombo which also generates a WMI > event which we want to translate to a key code to launch a > (to be written) debug-info collecting app for when the customer > calls Lenovo support. > > Mark suggested a new KEY_SYS_DEBUG_INFO for that. So do we use: > > #define KEY_INFO 0x166 /* AL OEM Features/Tips/Tutorial */ > > for this, or do we define a new keycode ? > > Mark would using KEY_INFO for this work for you. > > Dmitry any opinion on this ? No, my understanding is that Mark was OK with using KEY_VENDOR for Fn+N combination that is supposed to start the utility that would collect the debug info. For double click there is still the discussion whether to have KEY_DOUBLECLICK (which I think will need to be tied to the pointer device somehow), or something else, like KEY_CONFIG or a new keycode if we continue keeping it separate from the pointer operations and match Windows behavior which invokes Lenovo configuration utility. Thanks.
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? Thanks.
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. 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. 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? Mark
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. Thanks.
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. Mark
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. Regards, Hans
Hi, On 4/15/24 9: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? No when this was added most distros were still using X11 not Wayland so it was preferable to use KEY_foo symbols with codes below 240. > 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? That is a good question, at least my current ThinkPad does not have the Fn + F## combo for the control center anymore. So I guess we could indeed re-use KEY_CONFIG for the double-tap. Regards, Hans
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
Hi, On 4/16/24 2:48 PM, Mark Pearson wrote: > 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. Ok, PROG1 works for me. Regards, Hans
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 03edf2ccdf6c..bd3baca95749 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -686,6 +686,8 @@ #define KEY_SIDEVU_SONAR 0x287 #define KEY_NAV_INFO 0x288 #define KEY_BRIGHTNESS_MENU 0x289 +#define KEY_DOUBLECLICK 0x28a +#define KEY_SYS_DEBUG_INFO 0x28b /* * Some keyboards have keys which do not have a defined meaning, these keys