linux/drivers/hid/hid-multitouch.c

1752 lines
50 KiB

HID: multitouch: remove registered devices with default behavior The default multitouch protocol class in use since the kernel v3.9 is working quite well. Since its inclusion, the only devices we had to tweak were those who really need quirks (GeneralTouch, FocalTech and Wistron, the 3 of them are Win 7 certified ones). The flow of new unhandled devices has stopped, which is great and I think it's time to reduce the list of registered device. This commit removes only the registration in the kernel of devices that use the class MT_CLS_DEFAULT, or that can use it. By that, I mean that I checked all the recordings I have, and the produced input device and events are the same before and after applying the patch. This gives two benefits: - remove a bunch of lines of codes - prevent bad handling of existing registered devices which are using a different protocol while using the same VID/PID (I got the case of a Quanta 3008 recently). I also removed the associated classes (MT_CLS*). I kept their #define in case people use the new_id sysfs node with a non standard class (their should be really few people now, but we never now). This is why there are /* reserved .... */. Last, I add a comment on top of mt_devices[] definition to remember people (and myself) not to include devices for the beauty of it. To people still trying to add devices with the default class: """ Guys, try out your device under a kernel greater or equal to v3.9. If it works, you are all set. Adding your VID/PID to the kernel only brings us overload and you won't get anything from it _because_ even a backport of this shiny patch will _not_ make the device work under 3.0, 3.2, 3.4 or even 3.8. So if it works, it works. If it does not work, then yes, submit a patch or call for help. In any cases, if you want me to do regression tests, I'd be happy to get some traces of your device. But I won't patch the kernel if it works. """ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-02-28 11:41:23 -05:00
HID: multitouch: remove registered devices with default behavior The default multitouch protocol class in use since the kernel v3.9 is working quite well. Since its inclusion, the only devices we had to tweak were those who really need quirks (GeneralTouch, FocalTech and Wistron, the 3 of them are Win 7 certified ones). The flow of new unhandled devices has stopped, which is great and I think it's time to reduce the list of registered device. This commit removes only the registration in the kernel of devices that use the class MT_CLS_DEFAULT, or that can use it. By that, I mean that I checked all the recordings I have, and the produced input device and events are the same before and after applying the patch. This gives two benefits: - remove a bunch of lines of codes - prevent bad handling of existing registered devices which are using a different protocol while using the same VID/PID (I got the case of a Quanta 3008 recently). I also removed the associated classes (MT_CLS*). I kept their #define in case people use the new_id sysfs node with a non standard class (their should be really few people now, but we never now). This is why there are /* reserved .... */. Last, I add a comment on top of mt_devices[] definition to remember people (and myself) not to include devices for the beauty of it. To people still trying to add devices with the default class: """ Guys, try out your device under a kernel greater or equal to v3.9. If it works, you are all set. Adding your VID/PID to the kernel only brings us overload and you won't get anything from it _because_ even a backport of this shiny patch will _not_ make the device work under 3.0, 3.2, 3.4 or even 3.8. So if it works, it works. If it does not work, then yes, submit a patch or call for help. In any cases, if you want me to do regression tests, I'd be happy to get some traces of your device. But I won't patch the kernel if it works. """ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-02-28 11:41:23 -05:00
HID: multitouch: remove registered devices with default behavior The default multitouch protocol class in use since the kernel v3.9 is working quite well. Since its inclusion, the only devices we had to tweak were those who really need quirks (GeneralTouch, FocalTech and Wistron, the 3 of them are Win 7 certified ones). The flow of new unhandled devices has stopped, which is great and I think it's time to reduce the list of registered device. This commit removes only the registration in the kernel of devices that use the class MT_CLS_DEFAULT, or that can use it. By that, I mean that I checked all the recordings I have, and the produced input device and events are the same before and after applying the patch. This gives two benefits: - remove a bunch of lines of codes - prevent bad handling of existing registered devices which are using a different protocol while using the same VID/PID (I got the case of a Quanta 3008 recently). I also removed the associated classes (MT_CLS*). I kept their #define in case people use the new_id sysfs node with a non standard class (their should be really few people now, but we never now). This is why there are /* reserved .... */. Last, I add a comment on top of mt_devices[] definition to remember people (and myself) not to include devices for the beauty of it. To people still trying to add devices with the default class: """ Guys, try out your device under a kernel greater or equal to v3.9. If it works, you are all set. Adding your VID/PID to the kernel only brings us overload and you won't get anything from it _because_ even a backport of this shiny patch will _not_ make the device work under 3.0, 3.2, 3.4 or even 3.8. So if it works, it works. If it does not work, then yes, submit a patch or call for help. In any cases, if you want me to do regression tests, I'd be happy to get some traces of your device. But I won't patch the kernel if it works. """ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-02-28 11:41:23 -05:00
HID: multitouch: Fetch feature reports on demand for Win8 devices Some newer Intel Skylake based Dell laptops with Win8 precision touchpad fail when initial feature reports are fetched from it. Below is an example output with some additional debug included: i2c_hid i2c-DLL0704:01: Fetching the HID descriptor i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ... ... i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05 i2c_hid i2c-DLL0704:01: report id 13 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00 i2c_hid i2c-DLL0704:01: failed to retrieve report from device. i2c_hid i2c-DLL0704:01: report id 7 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ... i2c_hid i2c-DLL0704:01: report id 4 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00 We manage to fetch few reports but then the touchpad dies: i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0704:01: failed to retrieve report from device. it eventually pulls the whole I2C bus low: i2c_designware i2c_designware.1: controller timed out i2c_hid i2c-DLL0704:01: failed to set a report to device. Fix this by preventing initial feature report retrieval for Win8 devices. Instead we fetch reports as needed in mt_feature_mapping(). This prevents fetching reports which might cause problems with the device in question. Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-10-07 15:33:43 +03:00
HID: multitouch: Fetch feature reports on demand for Win8 devices Some newer Intel Skylake based Dell laptops with Win8 precision touchpad fail when initial feature reports are fetched from it. Below is an example output with some additional debug included: i2c_hid i2c-DLL0704:01: Fetching the HID descriptor i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ... ... i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05 i2c_hid i2c-DLL0704:01: report id 13 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00 i2c_hid i2c-DLL0704:01: failed to retrieve report from device. i2c_hid i2c-DLL0704:01: report id 7 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ... i2c_hid i2c-DLL0704:01: report id 4 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00 We manage to fetch few reports but then the touchpad dies: i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0704:01: failed to retrieve report from device. it eventually pulls the whole I2C bus low: i2c_designware i2c_designware.1: controller timed out i2c_hid i2c-DLL0704:01: failed to set a report to device. Fix this by preventing initial feature report retrieval for Win8 devices. Instead we fetch reports as needed in mt_feature_mapping(). This prevents fetching reports which might cause problems with the device in question. Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-10-07 15:33:43 +03:00
HID: multitouch: Fetch feature reports on demand for Win8 devices Some newer Intel Skylake based Dell laptops with Win8 precision touchpad fail when initial feature reports are fetched from it. Below is an example output with some additional debug included: i2c_hid i2c-DLL0704:01: Fetching the HID descriptor i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ... ... i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05 i2c_hid i2c-DLL0704:01: report id 13 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00 i2c_hid i2c-DLL0704:01: failed to retrieve report from device. i2c_hid i2c-DLL0704:01: report id 7 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ... i2c_hid i2c-DLL0704:01: report id 4 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00 We manage to fetch few reports but then the touchpad dies: i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0704:01: failed to retrieve report from device. it eventually pulls the whole I2C bus low: i2c_designware i2c_designware.1: controller timed out i2c_hid i2c-DLL0704:01: failed to set a report to device. Fix this by preventing initial feature report retrieval for Win8 devices. Instead we fetch reports as needed in mt_feature_mapping(). This prevents fetching reports which might cause problems with the device in question. Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-10-07 15:33:43 +03:00
HID: multitouch: fix input mode switching on some Elan panels as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481 This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other: The report descriptor declares two features in reports 3 and 5: 0x05, 0x0d, // Usage Page (Digitizers) 318 0x09, 0x0e, // Usage (Device Configuration) 320 0xa1, 0x01, // Collection (Application) 322 0x85, 0x03, // Report ID (3) 324 0x09, 0x22, // Usage (Finger) 326 0xa1, 0x00, // Collection (Physical) 328 0x09, 0x52, // Usage (Inputmode) 330 0x15, 0x00, // Logical Minimum (0) 332 0x25, 0x0a, // Logical Maximum (10) 334 0x75, 0x08, // Report Size (8) 336 0x95, 0x02, // Report Count (2) 338 0xb1, 0x02, // Feature (Data,Var,Abs) 340 0xc0, // End Collection 342 0x09, 0x22, // Usage (Finger) 343 0xa1, 0x00, // Collection (Physical) 345 0x85, 0x05, // Report ID (5) 347 0x09, 0x57, // Usage (Surface Switch) 349 0x09, 0x58, // Usage (Button Switch) 351 0x15, 0x00, // Logical Minimum (0) 353 0x75, 0x01, // Report Size (1) 355 0x95, 0x02, // Report Count (2) 357 0x25, 0x03, // Logical Maximum (3) 359 0xb1, 0x02, // Feature (Data,Var,Abs) 361 0x95, 0x0e, // Report Count (14) 363 0xb1, 0x03, // Feature (Cnst,Var,Abs) 365 0xc0, // End Collection 367 The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode. However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00". Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5. To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-12-01 12:41:38 +01:00
HID: multitouch: Fetch feature reports on demand for Win8 devices Some newer Intel Skylake based Dell laptops with Win8 precision touchpad fail when initial feature reports are fetched from it. Below is an example output with some additional debug included: i2c_hid i2c-DLL0704:01: Fetching the HID descriptor i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ... ... i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05 i2c_hid i2c-DLL0704:01: report id 13 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00 i2c_hid i2c-DLL0704:01: failed to retrieve report from device. i2c_hid i2c-DLL0704:01: report id 7 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ... i2c_hid i2c-DLL0704:01: report id 4 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00 We manage to fetch few reports but then the touchpad dies: i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0704:01: failed to retrieve report from device. it eventually pulls the whole I2C bus low: i2c_designware i2c_designware.1: controller timed out i2c_hid i2c-DLL0704:01: failed to set a report to device. Fix this by preventing initial feature report retrieval for Win8 devices. Instead we fetch reports as needed in mt_feature_mapping(). This prevents fetching reports which might cause problems with the device in question. Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-10-07 15:33:43 +03:00
HID: multitouch: Fetch feature reports on demand for Win8 devices Some newer Intel Skylake based Dell laptops with Win8 precision touchpad fail when initial feature reports are fetched from it. Below is an example output with some additional debug included: i2c_hid i2c-DLL0704:01: Fetching the HID descriptor i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ... ... i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05 i2c_hid i2c-DLL0704:01: report id 13 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00 i2c_hid i2c-DLL0704:01: failed to retrieve report from device. i2c_hid i2c-DLL0704:01: report id 7 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ... i2c_hid i2c-DLL0704:01: report id 4 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00 We manage to fetch few reports but then the touchpad dies: i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0704:01: failed to retrieve report from device. it eventually pulls the whole I2C bus low: i2c_designware i2c_designware.1: controller timed out i2c_hid i2c-DLL0704:01: failed to set a report to device. Fix this by preventing initial feature report retrieval for Win8 devices. Instead we fetch reports as needed in mt_feature_mapping(). This prevents fetching reports which might cause problems with the device in question. Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Tested-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2015-10-07 15:33:43 +03:00
HID: multitouch: remove registered devices with default behavior The default multitouch protocol class in use since the kernel v3.9 is working quite well. Since its inclusion, the only devices we had to tweak were those who really need quirks (GeneralTouch, FocalTech and Wistron, the 3 of them are Win 7 certified ones). The flow of new unhandled devices has stopped, which is great and I think it's time to reduce the list of registered device. This commit removes only the registration in the kernel of devices that use the class MT_CLS_DEFAULT, or that can use it. By that, I mean that I checked all the recordings I have, and the produced input device and events are the same before and after applying the patch. This gives two benefits: - remove a bunch of lines of codes - prevent bad handling of existing registered devices which are using a different protocol while using the same VID/PID (I got the case of a Quanta 3008 recently). I also removed the associated classes (MT_CLS*). I kept their #define in case people use the new_id sysfs node with a non standard class (their should be really few people now, but we never now). This is why there are /* reserved .... */. Last, I add a comment on top of mt_devices[] definition to remember people (and myself) not to include devices for the beauty of it. To people still trying to add devices with the default class: """ Guys, try out your device under a kernel greater or equal to v3.9. If it works, you are all set. Adding your VID/PID to the kernel only brings us overload and you won't get anything from it _because_ even a backport of this shiny patch will _not_ make the device work under 3.0, 3.2, 3.4 or even 3.8. So if it works, it works. If it does not work, then yes, submit a patch or call for help. In any cases, if you want me to do regression tests, I'd be happy to get some traces of your device. But I won't patch the kernel if it works. """ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-02-28 11:41:23 -05:00
HID: multitouch: remove registered devices with default behavior The default multitouch protocol class in use since the kernel v3.9 is working quite well. Since its inclusion, the only devices we had to tweak were those who really need quirks (GeneralTouch, FocalTech and Wistron, the 3 of them are Win 7 certified ones). The flow of new unhandled devices has stopped, which is great and I think it's time to reduce the list of registered device. This commit removes only the registration in the kernel of devices that use the class MT_CLS_DEFAULT, or that can use it. By that, I mean that I checked all the recordings I have, and the produced input device and events are the same before and after applying the patch. This gives two benefits: - remove a bunch of lines of codes - prevent bad handling of existing registered devices which are using a different protocol while using the same VID/PID (I got the case of a Quanta 3008 recently). I also removed the associated classes (MT_CLS*). I kept their #define in case people use the new_id sysfs node with a non standard class (their should be really few people now, but we never now). This is why there are /* reserved .... */. Last, I add a comment on top of mt_devices[] definition to remember people (and myself) not to include devices for the beauty of it. To people still trying to add devices with the default class: """ Guys, try out your device under a kernel greater or equal to v3.9. If it works, you are all set. Adding your VID/PID to the kernel only brings us overload and you won't get anything from it _because_ even a backport of this shiny patch will _not_ make the device work under 3.0, 3.2, 3.4 or even 3.8. So if it works, it works. If it does not work, then yes, submit a patch or call for help. In any cases, if you want me to do regression tests, I'd be happy to get some traces of your device. But I won't patch the kernel if it works. """ Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-02-28 11:41:23 -05:00