Hi Sebastian,
On Fri, Aug 30, 2013 at 07:59:46PM +0200, Sebastian Dalfuß wrote:
> In 3.6.x the egalax touch panel (Vendor: 0eef, Dev: 0001) worked
> perfectly well with hid-multitouch, right out of the box. In 3.9 and
> 3.10 it doesn't; the panel doesn't show up in /proc/bus/input/devices .
> If the module usbtouchscreen is present, 3.9/3.10 wrongly try to use
> that one (flipped y-axis, wrong scale, get's stuck) instead of
> hid-multitouch(worked previously perfectly well, no need for
> calibration, quirks, configuration). If usbtouchscreen isn't present,
> the panel isn't detected, even if hid-multitouch gets poked with appropriate
> parameters in /sys/module/hid_multitouch/drivers/hid\:hid-multitouch/new_id .
> In an desperate attempt, I manually added the device/vendor id to
> hid-multitouch.c, which didn't yield any improvement. It seems that the hid
> subsystem doesn't even recognize that this device is indeed a hid
> touchpanel.
That's probably this:
commit 729b814acec20db66fc891b5392cb653ad6598ef
Author: Forest Bond <forest.bond@xxxxxxxxxxxxxxxx>
Date: Tue Nov 6 13:41:22 2012 -0500
HID: Ignore D-WAV/eGalax devices handled by usbtouchscreen
Previously, both usbhid and usbtouchscreen would bind to D-WAV devices
with class HID and protocol None, so they would be claimed by whichever
driver was loaded first. Some of these devices do in fact work with
usbhid, but not all of them do. OTOH they all work with usbtouchscreen
as of commit 037a833ed05a86d01ea27a2c32043b86c549be1b ("Input:
usbtouchscreen - initialize eGalax devices"). So we ignore them in
usbhid to prevent getting in the way of usbtouchscreen and claiming an
interface that we may not be able to do anything useful with.
Signed-off-by: Forest Bond <forest.bond@xxxxxxxxxxxxxxxx>
Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>
The primary issue is that 0eef:0001 has been repeatedly re-used for a wide
variety of devices and as such cannot be meaningfully used on its own to select
a driver. Some of these devices have class HID and worked fine with
usbtouchscreen. When usbhid was introduced they stopped working because they
don't actually work with the HID driver.
Historically this is dealt with by submitting a patch that regresses everyone
else's screens but makes yours work better. ;)
So we need to figure out how to handle these devices. I need to dig out the
screen I have that did not work with the HID driver and test it again. Might
take some time for me to get to this.
> Is there a way to force hid to take care of that vendor/device-id, as a
> temporary workaround?
For now look at hid_ignore in hid-core.c. You can probably set
HID_QUIRK_NO_IGNORE to work around the problem. You'll probably also want to
blacklist usbtouchscreen.
Hope this helps.
Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.rapidrollout.com
Attachment:
signature.asc
Description: Digital signature
