On Mon, Jun 30, 2025 at 08:50:27PM +0900, Vishnu Sankar wrote: > Hi Dimitry, > > > On Mon, Jun 30, 2025 at 2:20 PM Dmitry Torokhov > <dmitry.torok...@gmail.com> wrote: > > > > Hi Mark, > > > > On Mon, Jun 30, 2025 at 05:42:45AM +0900, Mark Pearson wrote: > > > Hi Dmitry, > > > > > > On Fri, Jun 27, 2025, at 2:14 PM, Dmitry Torokhov wrote: > > > > Hi Vishnu, > > > > > > > > On Fri, Jun 20, 2025 at 09:42:08AM +0900, Vishnu Sankar wrote: > > > >> Newer ThinkPads have a doubletap feature that needs to be turned > > > >> ON/OFF via the trackpoint registers. > > > >> Systems released from 2023 have doubletap disabled by default and > > > >> need the feature enabling to be useful. > > > >> > > > >> This patch introduces support for exposing and controlling the > > > >> trackpoint doubletap feature via a sysfs attribute. > > > >> /sys/devices/platform/thinkpad_acpi/tp_doubletap > > > >> This can be toggled by an "enable" or a "disable". > > > >> > > > >> With this implemented we can remove the masking of events, and rely on > > > >> HW control instead, when the feature is disabled. > > > >> > > > >> Note - Early Thinkpads (pre 2015) used the same register for hysteris > > > >> control, Check the FW IDs to make sure these are not affected. > > > >> > > > >> trackpoint.h is moved to linux/input/. > > > > > > > > No, please keep everything private to trackpoint.c and do not involve > > > > thinkpad_acpi driver. By doing so you are introducing unwanted > > > > dependencies (for both module loading, driver initialization, and > > > > operation) and unsafe use of non-owned pointers/dangling pointers, etc. > > > > > > > > > > Do you have recommendations on how to handle this case then? > > > > > > This is a Thinkpad specific feature and hence the logic for involving > > > thinkpad_acpi. There are Thinkpad hotkeys that will enable/disable the > > > trackpoint doubletap feature - so there is some linkage. I'm not sure > > > how to avoid that. > > > > > > Is there a cleaner way to do this that you'd recommend we look at > > > using? It's a feature (albeit a minor one) on the laptops that we'd > > > like to make available to Linux users. > > > > I believe if you define the doubletap as an attribute (see > > TRACKPOINT_INT_ATTR or TRACKPOINT_BIT_ATTR in > > drivers/input/mouse/trackpoint.c) then whatever process is handling the > > hot keys switching this function on or off should be able to toggle the > > behavior. The difference is that it will have to locate trackpoint node > > in /sys/bus/serio/devices/* (or maybe scan > > /sys/devices/platform/i8042/serio*) instead of expecting the attributes > > be atached to thinkpad_acpi instance. > > > > You just don't want to have one driver directly peeking into another, > > because then it starts breaking if you unbind or force use of a > > different protocol, etc. > > > > Thanks. > > > > -- > > Dmitry > > Thanks for the suggestion. I understand the concern about avoiding > direct driver-to-driver calls and unwanted dependencies. > > Just to clarify: if we move the sysfs attribute to the trackpoint > driver itself (under /sys/bus/serio/devices/...), then thinkpad_acpi > would no longer be able to directly enable/disable the doubletap > feature in response to the Fn+G hotkey press. Don't we need userspace > to listen for the hotkey event, find the trackpoint sysfs node, and > toggle the attribute there?
Yes. > That's possible, of course, but it means the feature won't work > out-of-the-box without extra userspace integration. For example, there > would be no automatic linkage between pressing Fn+G and toggling the > feature unless a udev rule or userspace daemon is configured to do it. > Or is there an approach you'd recommend to preserve the automatic > hotkey integration while avoiding the direct dependency between > thinkpad_acpi and trackpoint? > Sorry, I missed something. Well, I guess you can look into interacting with sysfs file from thinkpad_acpi.c... There is kernel_read_file_from_path() and others, you will need to implement write counterpart of it. Pretty ugly but safer than following pointers that may go away. Thanks. -- Dmitry _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
