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:
signature.asc
Description: Digital signature
