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