]> git.baikalelectronics.ru Git - kernel.git/commit
HID: don't ignore eGalax/D-Wav/EETI HIDs
authorForest Bond <forest.bond@rapidrollout.com>
Mon, 21 Oct 2013 16:38:02 +0000 (12:38 -0400)
committerJiri Kosina <jkosina@suse.cz>
Mon, 11 Nov 2013 10:19:26 +0000 (11:19 +0100)
commit8fcce1bdd66f5790bea83711cecb03db2173402d
tree1674b11dfe9239f4faf0491ce7977488da818ae6
parent556f9cfb8b0a6dcf565587d452747fb2775a5f3d
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 ffbd6dd ("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:

8891db5 HID: add multi-input quirk for eGalax Touchcontroller
8901bfb Merge branch 'egalax' into for-linus
99e14df HID: Add quirk for eGalax touch controler.
af9f0d5 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>
drivers/hid/hid-core.c