|
From: Dmitry T. <dmi...@gm...> - 2025-09-19 01:12:41
|
On Thu, Sep 18, 2025 at 09:31:47AM +0200, Hans de Goede wrote: > Hi Vishnu, > > On 18-Sep-25 4:37 AM, Vishnu Sankar wrote: > > Hello all, > > > > Do we have any questions or concerns? > > Thanks in advance! > > > > On Mon, Sep 1, 2025 at 10:53 PM Vishnu Sankar <vis...@gm...> wrote: > >> > >> Add support for enabling and disabling doubletap on TrackPoint devices > >> that support this functionality. The feature is detected using firmware > >> ID and exposed via sysfs as `doubletap_enabled`. > > Hmm, you seem to be using a firmware ID prefix match, combined with > a deny list of some firmware IDs with that prefix which do not support > this. How do we know this deny list is complete? > > Also as Dmitry says you really should use the is_visible() callback > to not show the attribute at all on unsupported systems. > > >> The feature is only available on newer ThinkPads (2023 and later).The driver > >> exposes this capability via a new sysfs attribute: > >> "/sys/bus/serio/devices/seriox/doubletap_enabled". > >> > >> The attribute is only created if the device is detected to be capable of > >> doubletap via firmware and variant ID checks. This functionality will be > >> used by platform drivers such as thinkpad_acpi to expose and control doubletap > >> via user interfaces. > > Hmm, you refer to thinkpad_acpi as a possible consumer of this > functionality. But you only add a sysfs interface. > > thinkpad_acpi will need some in kernel interface to use this. > > Which brings me to my main question: thinkpad_acpi is the driver > receiving the doubletap events since these are send out-of-bound > and not through the ps/2 trackpoint protocol. > > thinkpad_acpi already has the capability to filter out these doubletap > events and report nothing. Why is it necessary / better to disable > the doubletap at the trackpoint fw-level, rather then just filtering > it at the thinkpad_acpi level ? > > I don't really see a big advantage in filtering these events at > the fw-level rather then in the kernel and we already have the > in kernel filtering. That is an excellent observation, thank you Hans. The frequency of these events should be extremely low, so cost of simply ignoring events should be miniscule... Thanks. -- Dmitry |
