| Message ID | 20210107112708.25990-1-hui.wang@canonical.com |
|---|---|
| State | New |
| Headers | show |
| Series | HID: multitouch: add a quirk to skip set inputmode for 2 new laptops | expand |
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 Regards, Barnabás Pőcze
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 >
This turns out to be a firmware issue, synaptics provided a new firmware for the touchpad, and we upgraded the firmware for the touchpad under windows (we only have windows firmware upgrade utility), now the touchpad could work with trackpoint together under Linux. Thanks. On 1/9/21 8:35 PM, Hui Wang wrote: > > 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 >>
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c index 0743ef51d3b2..3a658c4b4b05 100644 --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -70,6 +70,7 @@ MODULE_LICENSE("GPL"); #define MT_QUIRK_WIN8_PTP_BUTTONS BIT(18) #define MT_QUIRK_SEPARATE_APP_REPORT BIT(19) #define MT_QUIRK_FORCE_MULTI_INPUT BIT(20) +#define MT_QUIRK_SKIP_SET_INPUTMODE BIT(21) #define MT_INPUTMODE_TOUCHSCREEN 0x02 #define MT_INPUTMODE_TOUCHPAD 0x03 @@ -191,6 +192,7 @@ static void mt_post_parse(struct mt_device *td, struct mt_application *app); #define MT_CLS_EXPORT_ALL_INPUTS 0x0013 /* reserved 0x0014 */ #define MT_CLS_WIN_8_FORCE_MULTI_INPUT 0x0015 +#define MT_CLS_WIN_8_SKIP_SET_INPUTMODE 0x0016 /* vendor specific classes */ #define MT_CLS_3M 0x0101 @@ -283,6 +285,15 @@ static const struct mt_class mt_classes[] = { MT_QUIRK_WIN8_PTP_BUTTONS | MT_QUIRK_FORCE_MULTI_INPUT, .export_all_inputs = true }, + { .name = MT_CLS_WIN_8_SKIP_SET_INPUTMODE, + .quirks = MT_QUIRK_ALWAYS_VALID | + MT_QUIRK_IGNORE_DUPLICATES | + MT_QUIRK_HOVERING | + MT_QUIRK_CONTACT_CNT_ACCURATE | + MT_QUIRK_STICKY_FINGERS | + MT_QUIRK_WIN8_PTP_BUTTONS | + MT_QUIRK_SKIP_SET_INPUTMODE, + .export_all_inputs = true }, /* * vendor specific classes @@ -1419,6 +1430,8 @@ static bool mt_need_to_apply_feature(struct hid_device *hdev, switch (usage->hid) { case HID_DG_INPUTMODE: + if (cls->quirks & MT_QUIRK_SKIP_SET_INPUTMODE) + return false; /* * Some elan panels wrongly declare 2 input mode features, * and silently ignore when we set the value in the second @@ -2058,6 +2071,11 @@ static const struct hid_device_id mt_devices[] = { HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8, USB_VENDOR_ID_SYNAPTICS, 0xce09) }, + /* Synaptics devices */ + { .driver_data = MT_CLS_WIN_8_SKIP_SET_INPUTMODE, + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8, + USB_VENDOR_ID_SYNAPTICS, 0xce57) }, + /* TopSeed panels */ { .driver_data = MT_CLS_TOPSEED, MT_USB_DEVICE(USB_VENDOR_ID_TOPSEED2,
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. Signed-off-by: Hui Wang <hui.wang@canonical.com> --- drivers/hid/hid-multitouch.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)