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>
The usage Confidence is mandary to Windows Precision Touchpad devices. The
appearance of this usage is checked in hidinput_connect but the quirk
MT_QUIRK_VALID_IS_CONFIDENCE is not applied to device accordingly.
Apply this quirk and also remove quirk MT_QUIRK_ALWAYS_VALID to enable palm
rejection for the WIN 8 touchpad devices which have implemented usage
Confidence in its input reports.
Tested on Dell XPS 13 laptop.
Signed-off-by: Allen Hung <allen_hung@dell.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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>
Fields like HID_DG_CONTACTCOUNT are outside of the physical collection,
but within the application collection and report ID. Make sure to catch
those fields that are not part of the mt_report_id and return 0 so they
can be processed with the pen. Otherwise, the wrong HID_DG_CONTACTCOUNT
will be applied to cc_index and result in dereferencing a null pointer in
mt_touch_report.
Signed-off-by: Brent Adam <brentadam@smarttech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
According to [1], Windows Precision Touchpad devices must supply
a button type usage in the device capabilities feature report. A
value of 0 indicates that the device contains a depressible
button (i.e. it's a click-pad) whereas a value of 1 indicates
a non-depressible button. Add support for this usage and set
INPUT_PROP_BUTTONPAD on the touchpad input device whenever a
depressible button is present.
[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Touchpads that have only one button are called clickpads and should
be advertised as such by the kernel.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
These 2 are left over from the USB dependency cleaning, so there is
no need to keep them.
[jkosina@suse.cz: fix filename]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
In several hid drivers it is necessary to calculate the length of an
hid_report. This patch exports the existing static function hid_report_len of
hid-core.c as an inline function in hid.h
Signed-off-by: Mathieu Magnaudet <mathieu.magnaudet@enac.fr>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
VTL panels do not switch to the multitouch mode until the input mode
feature is read by the host. This should normally be done by
usbhid, but it looks like an other bug prevents usbhid to properly
retrieve the feature state. As a workaround, we force the reading of
the feature in mt_set_input_mode for such devices.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Mathieu Magnaudet <mathieu.magnaudet@enac.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Multitouch touchpads built for Win 8.1 need to be sent an input mode feature report
in order to start reporting multitouch events. This is the same process sent
to Win 7 multitouch touchscreens except the value of the feature report is 3 for
touchpads.
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The ANTON Touch Pad is a device which can switch from a multitouch
touchpad to a mouse. It thus presents several generic collections which
are currently ignored by hid-multitouch. Enable them by not ignoring
them in mt_input_mapping.
Adding also a suffix for them depending on their application.
Reported-by: Edel Maks <edelmaks@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pens have a special handling in hid-mt as hybrid pen/touch devices
are quite common now. However, some fancy devices presents also
useful collections like mouse or keyboard.
The special case for the pen may not be a special case, and treat it as
a generic case.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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>
This is a Win7 device which does not work correctly with the default
settings (not the previous default BT).
However, the quirk ALWAYS_TRUE makes it working like a charm.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Jiri Kosina
Geliang Tang
Benjamin Tissoires
Allen Hung
Mika Westerberg
Dmitry Torokhov
Yang Bo
Brent Adam
Seth Forshee
Mathieu Magnaudet
Tomas Sokorai
Andrew Duggan