linux-kernel - Re: [PATCH v3] hid/hid-multitouch: Keep latency normal on deactivate for reactivation gesture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ee5388c1-c341-4563-b239-919bc4d0a334@tuxedocomputers.com>
Date: Fri, 19 Dec 2025 16:55:50 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Benjamin Tissoires <bentiss@...nel.org>
Cc: Jiri Kosina <jikos@...nel.org>, linux-input@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] hid/hid-multitouch: Keep latency normal on deactivate
 for reactivation gesture


Am 19.12.25 um 14:10 schrieb Benjamin Tissoires:
> On Nov 12 2025, Werner Sembach wrote:
>> Am 12.11.25 um 15:47 schrieb Werner Sembach:
>>> Uniwill devices have a built in gesture in the touchpad to de- and
>>> reactivate it by double taping the upper left corner. This gesture stops
>>> working when latency is set to high, so this patch keeps the latency on
>>> normal.
>>>
>>> Signed-off-by: Werner Sembach <wse@...edocomputers.com>
>>> Cc: stable@...r.kernel.org
>>> ---
>>> V1->V2: Use a quirk to narrow down the devices this is applied to.
>>> V2->V3: Fix this patch breaking touchpads on some devices.
>>>           Add another device ID.
>>>
>>> I have three Uniwill devices at hand right now that have at least two
>>> physically different touchpads, but same Vendor + Product ID combination.
>>> Maybe the vendor uses this product ID for all i2c connected touchpads, or
>>> it is used as some kind of subvendor ID to indicate Uniwill?
>>>
>>> To be able to really narrow it down to Uniwill only devices I would need to
>>> check DMI strings, but then I will probably narrow it down to much as I
>>> only know what we at TUXEDO use there.
>>>
>>>    drivers/hid/hid-multitouch.c | 26 +++++++++++++++++++++++++-
>>>    1 file changed, 25 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>>> index 179dc316b4b51..ed9eb4e0d5038 100644
>>> --- a/drivers/hid/hid-multitouch.c
>>> +++ b/drivers/hid/hid-multitouch.c
>>> @@ -76,6 +76,7 @@ MODULE_LICENSE("GPL");
>>>    #define MT_QUIRK_DISABLE_WAKEUP		BIT(21)
>>>    #define MT_QUIRK_ORIENTATION_INVERT	BIT(22)
>>>    #define MT_QUIRK_APPLE_TOUCHBAR		BIT(23)
>>> +#define MT_QUIRK_KEEP_LATENCY_ON_CLOSE	BIT(24)
>>>    #define MT_INPUTMODE_TOUCHSCREEN	0x02
>>>    #define MT_INPUTMODE_TOUCHPAD		0x03
>>> @@ -211,6 +212,7 @@ static void mt_post_parse(struct mt_device *td, struct mt_application *app);
>>>    #define MT_CLS_WIN_8_DISABLE_WAKEUP		0x0016
>>>    #define MT_CLS_WIN_8_NO_STICKY_FINGERS		0x0017
>>>    #define MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU	0x0018
>>> +#define MT_CLS_WIN_8_KEEP_LATENCY_ON_CLOSE	0x0019
>> A college realized that at some points in the code some, but not all, of the
>> MT_CLS_WIN_8* classes are checked for directly. Should I add my new class
>> there too?
> It depends. If it's truely a WIN_8 touchpad then I guess those checks
> are here for a reason, but if this particular device works without them,
> then it's your call in the end.

Didn't notice a difference, but will it include anyway to be on the safe side.

v4 incoming

>
> Cheers,
> Benjamin