diff options
author | Forest Bond <forest.bond@rapidrollout.com> | 2013-10-21 12:38:02 -0400 |
---|---|---|
committer | Jiri Kosina <jkosina@suse.cz> | 2013-11-11 11:19:26 +0100 |
commit | 95d50b6c5e18ff7351c5f2a6ff53afaed5f7e664 (patch) | |
tree | 1674b11dfe9239f4faf0491ce7977488da818ae6 /drivers/input/touchscreen/usbtouchscreen.c | |
parent | 6d60332610e213b8a5a8deaecfd7d561de1e98e4 (diff) |
HID: don't ignore eGalax/D-Wav/EETI HIDs
Certain devices with class HID, protocol None did not work with the HID
driver at one point, and as a result were bound to usbtouchscreen
instead as of commit 139ebe8 ("Input: usbtouchscreen - fix eGalax HID
ignoring"). This change was prompted by the following report:
https://lkml.org/lkml/2009/1/25/127
Unfortunately, the device mentioned in this report is no longer
available for testing.
We've recently discovered that some devices with class HID, protocol
None do not work with usbtouchscreen, but do work with usbhid. Here is
the report that made this evident:
http://comments.gmane.org/gmane.linux.kernel.input/31710
Driver binding for these devices has flip-flopped a few times, so both
of the above reports were regressions.
This situation would appear to leave us with no easy way to bind every
device to the right driver. However, in my own testing with several
devices I have not found a device with class HID that does not work with
the current HID driver. It is my belief that changes to the HID driver
since the original report have likely fixed the issue(s) that made it
unsuitable at the time, and that we should prefer it over usbtouchscreen
for these devices. In particular, HID quirks affecting these devices
were added/removed in the following commits since then:
fe6065d HID: add multi-input quirk for eGalax Touchcontroller
77933c3 Merge branch 'egalax' into for-linus
ebd11fe HID: Add quirk for eGalax touch controler.
d34c4aa HID: add no-get quirk for eGalax touch controller
This patch makes the HID driver no longer ignore eGalax/D-Wav/EETI
devices with class HID. If there are in fact devices with class HID
that still do not work with the HID driver, we will see another round of
regressions. In that case I propose we investigate why the device is
not working with the HID driver rather than re-introduce regressions for
functioning HID devices by again binding them to usbtouchscreen.
The corresponding change to usbtouchscreen will be made separately.
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Diffstat (limited to 'drivers/input/touchscreen/usbtouchscreen.c')
0 files changed, 0 insertions, 0 deletions