On Wed, Oct 4, 2023, at 19:29, Rahul Rameshbabu wrote: > On Wed, 04 Oct, 2023 12:01:27 -0700 "Rain" <rain@xxxxxxxxxxxxx> wrote: >> On Sun, Sep 17, 2023, at 09:18, Rahul Rameshbabu wrote: >>> Register the Synaptics device as a special multitouch device with certain >>> quirks that may improve usability of the touchpad device. >>> >>> Reported-by: Rain <rain@xxxxxxxxxxxxx> >>> Closes: >>> https://lore.kernel.org/linux-input/2bbb8e1d-1793-4df1-810f-cb0137341ff4@xxxxxxxxxxxxxxxx/ >>> Signed-off-by: Rahul Rameshbabu <sergeantsagara@xxxxxxxxxxxxxx> >>> --- >>> >>> Notes: >>> Theory: >>> >>> I think the Synaptics device in the related email to the linux-input >>> mailing list requires certain quirks like MT_QUIRK_HOVERING to correctly >>> reconfigure the distance configuration for multitouch events. This might >>> explain why light touches were not registered originally when >>> MT_CLS_DEFAULT was used by default for the device. Would like to have >>> this patch tested before being merged. A Tested-by: git trailer can then >>> be appended. >>> >>> drivers/hid/hid-multitouch.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c >>> index 521b2ffb4244..8db4ae05febc 100644 >>> --- a/drivers/hid/hid-multitouch.c >>> +++ b/drivers/hid/hid-multitouch.c >>> @@ -2144,6 +2144,10 @@ static const struct hid_device_id mt_devices[] = { >>> USB_DEVICE_ID_MTP_STM)}, >>> >>> /* Synaptics devices */ >>> + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT, >>> + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8, >>> + USB_VENDOR_ID_SYNAPTICS, 0xcd7e) }, >> >> Thanks for the patch! I haven't tested it yet but it looks promising. >> >> The vendor ID isn't USB_VENDOR_ID_SYNAPTICS (0x06cb), >> however -- it's SYNA7DB5 (0x7db5) which I guess is an alternative vendor >> ID for Synaptics. Would be worth fixing that. > > Hi Rain, > > I think you might be confusing the device name string with the vendor > id, based on my interpretation of the output you shared. > > [ 2.034760] input: SYNA7DB5:00 06CB:CD7E Mouse as > /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA7DB5:00/0018:06CB:CD7E.0001/input/input1 > [ 2.034865] input: SYNA7DB5:00 06CB:CD7E Touchpad as > /devices/platform/AMDI0010:00/i2c-0/i2c-SYNA7DB5:00/0018:06CB:CD7E.0001/input/input2 > > The first column has a device name but what we are interested in is the > second column, '06CB:CD7E'. 0x06CB is the vendor id and 0xCD7E is the > device id. Hope that makes sense and let me know if you think this is > off. Ah, got it, thank you! I was definitely misreading what was going on and was a bit thrown off by the "SYNA7DB5". Sorry about the confusion. > In general for these types of issues, I think the right direction would > be to make quirks loadable in userspace through HID-BPF where DEs or > some systemd subsystem can help users load quirks needed for their HID > devices rather than building a list of quirks in the driver. This is > something I am interested in exploring. That would definitely be very interesting. Thanks again for the fix.
