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. -- Dmitry
