Re: [PATCH] HID: multitouch: add a quirk to skip set inputmode for 2 new laptops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 1/7/21 8:42 PM, Barnabás Pőcze wrote:
Hi


2021. január 7., csütörtök 12:27 keltezéssel, Hui Wang írta:

we have 2 latest Thinkpad laptops, the synaptics trackpoint module is
connected to i8042 bus and the synaptics touchpad module is on the i2c
bus. The trackpoint is driven by input/mouse/trackpoint.c and the
touchpad is driven by hid-multitouch.c.

They all work well independently, but if users press any buttons of
trackpoint and meanwhile move finger on the touchpad, the touchpad
can't work, the i2c bus can't generate interrupts even. That is to say
the touchpad can't work with trackpoint together, once trackpoint
works, the touchpad stops working.

The current hid driver parses the device descriptor and selects the
hid-multitouch.c and applies the MT_CLS_WIN_8 to the touchpad, I found
this issue begins to happen after the driver sets the
MT_INPUTMODE_TOUCHPAD to the device, If skipping to set it, the
touchpad work well and doesn't have that issue, even after suspend and
resume, the touchpad still work well.

This touchpad module doesn't support multi inputmodes, and its init
mode is set by BIOS already, it is safe to skip to set it again in
the kernel driver.
[...]
Assuming I'm not missing anything obvious, a windows precision touchpad
should revert back to reporting events via its HID compliant mouse collection
when power cycled or reset by the host[1].

Doesn't that imply that the events will be reported via the mouse collection
in this case, and that the multi-touch capabilities of the device will not
be usable? Or am I missing something?


[1]: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections#input-mode-feature-report

Yes, you are right, after applying this patch, the events will be reported through mouse collection and some features specific to touchpad collection like multi-touch are lost. So this patch is not a correct solution, please ignore this patch.

And I found If using the hid-rmi.c to drive this touchpad, it will work well, the touchpad and trackpoint could work well together and the touchpad has multi-touch capability. But because the report descriptor contains an Input item which has the usage HID_DG_CONTACTID, the hid->group is set to HID_GROUP_MULTITOUCH, the hid-multitouch.c is selected to drive this touchpad.

Is it Okay to do the change below and let hid-rmi.c drive this touchpad?

diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 311eee599ce9..58a7529499f5 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -759,6 +759,7 @@ static const struct hid_device_id rmi_id[] = {
        { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_REZEL) },         { HID_USB_DEVICE(USB_VENDOR_ID_SYNAPTICS, USB_DEVICE_ID_SYNAPTICS_ACER_SWITCH5),
                .driver_data = RMI_DEVICE_OUTPUT_SET_REPORT },
+       { HID_I2C_DEVICE(USB_VENDOR_ID_SYNAPTICS, 0xce57) },
        { HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID) },
        { }
 };

Thanks,

Hui.



Regards,
Barnabás Pőcze




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux