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/