Fixing 0eef:0001 (eGalax) driver binding

Fixing 0eef:0001 (eGalax) driver binding

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]

Hi,

[If you're Cc'd it's because I thought you would be interested—except for Max!
Max, I was hoping for some quick help if you still have that eGalax touch screen
you reported about back in 2009.]


To review, these are devices with vendor ID 0eef and product ID 0001 (or 0002,
which I've never actually seen myself) with varying interfaces class, subclass,
and protocol.  Different devices have worked with different mainline drivers to
varying degrees over the years.  It has never been entirely clear how to
(automatically) select a driver to bind to a particular device.

There is some history to this situation that I will not describe in detail here
as I think it is most beneficial to focus on the present situation.  To that
end, here are the relevant points of interest (to the best of my knowledge):

1. Devices with vendor specific class and protocol apparently work fine with
   usbtouchscreen, which is where they are bound.  Nice!

2. Devices with class HID, protocol Mouse apparently work fine with usbhid,
   which is where they are bound.  Woo hoo!

3. Some devices with class HID, protocol None work fine with usbtouchscreen,
   which is where they are currently bound.  Okay!

   Some of these also work with usbhid (using quirks=0x20000048 to prevent it
   from being ignored).  All of the ones I have here are like this.  I'm not
   sure if there is a reason to prefer one driver over the other (dual touch?).

   Others reportedly do *not* work with usbhid (this is Max):

   https://lkml.org/lkml/2009/1/25/127

4. Some devices with class HID, protocol None do *not* work with usbtouchscreen,
   which is where they are currently bound.  No bueno.  Here's one (this is
   Sebastian):

   http://comments.gmane.org/gmane.linux.kernel.input/31710

   I suspect these are all multitouch devices, but I am not sure.

So we need to figure out the device driver mapping that supports the most
devices (or regresses the fewest, although I think we've messed this up enough
for that to be a secondary concern).


What I'm hoping is that the report in #3 that led to class HID, protocol None
devices being bound to usbtouchscreen is no longer accurate and these devices
work fine with current usbhid.

Max, can you test this for us?  I.e. does your touch screen work with current
usbhid using quirks=0x20000048?  The following modprobe snippet might be
helpful:

options usbhid quirks=0x0eef:0x0001:0x40000048
install usbtouchscreen /bin/false

If Max's touch screen works with current usbhid, I think we can drop the special
case that binds it to usbtouchscreen and we're done!  If not, things will be
more complicated (e.g. we may have to consider whether a device is multitouch to
decide if we should bind usbhid or usbtouchscreen).


Hope we can get it sorted.  Thanks for your help and input.

Regards,
Forest
-- 
Forest Bond
http://www.forestbond.com/
http://www.rapidrollout.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Fixing 0eef:0001 (eGalax) driver binding

[Forest Bond]

[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]

Hi,

On Tue, Oct 15, 2013 at 02:27:01PM -0400, Forest Bond wrote:
> 3. Some devices with class HID, protocol None work fine with usbtouchscreen,
>    which is where they are currently bound.  Okay!
> 
>    Some of these also work with usbhid (using quirks=0x20000048 to prevent it
>    from being ignored).  All of the ones I have here are like this.  I'm not
>    sure if there is a reason to prefer one driver over the other (dual touch?).
> 
>    Others reportedly do *not* work with usbhid (this is Max):
> 
>    https://lkml.org/lkml/2009/1/25/127
> 
> 4. Some devices with class HID, protocol None do *not* work with usbtouchscreen,
>    which is where they are currently bound.  No bueno.  Here's one (this is
>    Sebastian):
> 
>    http://comments.gmane.org/gmane.linux.kernel.input/31710
> 
>    I suspect these are all multitouch devices, but I am not sure.
> 
> So we need to figure out the device driver mapping that supports the most
> devices (or regresses the fewest, although I think we've messed this up enough
> for that to be a secondary concern).
> 
> 
> What I'm hoping is that the report in #3 that led to class HID, protocol None
> devices being bound to usbtouchscreen is no longer accurate and these devices
> work fine with current usbhid.
> 
> Max, can you test this for us?  I.e. does your touch screen work with current
> usbhid using quirks=0x20000048?  The following modprobe snippet might be
> helpful:
> 
> options usbhid quirks=0x0eef:0x0001:0x40000048
> install usbtouchscreen /bin/false
> 
> If Max's touch screen works with current usbhid, I think we can drop the special
> case that binds it to usbtouchscreen and we're done!  If not, things will be
> more complicated (e.g. we may have to consider whether a device is multitouch to
> decide if we should bind usbhid or usbtouchscreen).

Max reported to me off-list that he no longer has his touch screen, so this
testing most likely will not be taking place.

Unless someone can identify an EETI/eGalax touch screen with class HID, protocol
None that does not work with current usbhid, I propose we bind these to usbhid
instead of usbtouchscreen and see if anything breaks.  This will fix one
regression (Sebastian's) at the risk of re-introducing another one (Max's).  But
I think we'll actually end up with both problems fixed.

I think I could also argue that if we're going to break a device, it should be
the one that says it's HID but isn't, not the one that actually is what it says
it is.  Hopefully it won't come down to that. ;)

Thoughts?

Thanks,
Forest
-- 
Forest Bond
http://www.forestbond.com/
http://www.rapidrollout.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]