Re: Researching An Experimental Touchscreen Driver

[Jeremy Moles <jeremy@emperorlinux.com>]

On Sat, 2010-11-27 at 19:07 -0800, Dmitry Torokhov wrote:
> On Sat, Nov 27, 2010 at 09:23:30PM -0500, Jeremy Moles wrote:
> > On Sat, 2010-11-27 at 15:51 -0800, Dmitry Torokhov wrote:
> > > On Wed, Nov 24, 2010 at 11:07:00AM -0500, Jeremy Moles wrote:
> > > > Hello everyone! I have a piece of hardware here using a vanilla 2.6.34
> > > > kernel (though I can easily change kernels if needed) that has attached
> > > > to it internally a USB touchscreen device. The relevant DMESG info is
> > > > below, and this is printed out whenever the module 'usbhid' is loaded.
> > > > 
> > > > --------------------------------------------------------------------
> > > > 
> > > > usbcore: registered new interface driver hiddev
> > > > input: Fujitsu Component USB Touch Panel
> > > > as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/input/input9
> > > > generic-usb 0003:0430:0501.0002: input: USB HID v1.00 Mouse [Fujitsu
> > > > Component USB Touch Panel] on usb-0000:00:1a.0-2/input0
> > > > usbcore: registered new interface driver usbhid
> > > > usbhid: USB HID core driver
> > > > 
> > > > --------------------------------------------------------------------
> > > > 
> > > > For a long time now, we have been successfully configuring these
> > > > machines using the device node created when this driver is loaded, often
> > > > something like /dev/input/event5 (with a UDEV rule to make the name more
> > > > sensible). In X, we've been using the "evtouch" driver with this device
> > > > node, to great effect.
> > > > 
> > > > However, I am doing a bit of research and experimentation, and what I
> > > > would like to do is write some custom driver code to interface with this
> > > > device, instead of letting usbhid manage it. My question is, where is
> > > > the best place to start?
> > > 
> > > I guess you need to enumerate what deficiencies usbhid has and what
> > > issues you want to solve. That would clear a lot. I think that
> > > completely abandoning HID driver for device that is mostly HID compliant
> > > is not the best idea and you probably want to wire a HID sub-driver that
> > > works in tandem with usbhid.
> > 
> > I think you're absolutely right about a sub-driver of sorts.
> > 
> > Essentially it comes down to this: the touchscreen is being used in
> > hardware running Android, and the Android userspace code expects an
> > input event device to support the BTN_TOUCH ioctl. However, seeing as
> > usbhid binds to this device in a very generic way, it doesn't add the
> > BTN_TOUCH bits, and rightly so. In regular X, the evtouch driver does
> > not require this particular feature, so the device works fine.
> > 
> > HOWEVER, if I remove this check from the Android userspace library tslib
> > (the ioctl query for BTN_TOUCH), it does at least act as a pointer
> > inside Android's display manager, although there is no notion of
> > pressure--it's either 255 or 0 in tslib terms. I'm not entirely sure the
> > device even supports pressure, but that is why I'm researching this
> > project. :)
> > 
> > > > 
> > > > - Since usbhid already recognizes and binds to this device, what code
> > > > can I begin studying to see exactly how it's detecting this and
> > > > formatting input?
> > > 
> > > I guess drivers/hid/hid-input.c is the most interesting one.
> > > 
> > > > 
> > > > - Once usbhid attaches to this device, is the device in some kind of
> > > > lock? Is it possible to simply inject additional features or formatting
> > > > functions, possibly via quirks? (I don't quite understand how to do
> > > > anything with quirks other than blacklist a device).
> > > 
> > > Only one driver can manage a device so once HID claimed it your
> > > standalone driver will not be able to control it. However there is
> > > notion of HID bus drivers (you looked at hid-ntrig - it's one of them)
> > > that allow you to override and/or augment processing done by the default
> > > HID driver.
> > 
> > This is definitely what I'm interested in. I stripped its code down to
> > basically just the probe function. It recognizes my USB PCIID but fails
> > to call hid_parse() with the error -19. I've not been able to lock down
> > where the ll_driver->hid_parse() function is to see exactly what this
> > error might be.
> > 
> > > > 
> > > > - If I want to write a full driver for the device, what source file
> > > > would be best to start from? I've tried hacking usbtouchscreen.c and
> > > > hid-ntrig.c for the last few days to try and get them to bind to the
> > > > device, but neither attempt has seen any success. My hid-ntrig change
> > > > refuses to successfully call hid_parse(), and my usbtouchscreen change
> > > > continually returns some error code in the IRQ callback.
> > > 
> > > Did you add the VID/PID of your device to the blacklist in
> > > drivers/hid/hid-core.c?
> > 
> > Yes, and this does prevent usbhid from picking it up. I can also add a
> > quirk to modprobe.conf dynamically adding the HID_QUIRK_IGNORE quirk to
> > achieve the same effect. In fact, this is necessary for my "hacked"
> > hid-testdriver.c module to even TRY and call the probe function.
> 
> Well, if you add HID_QUIRK_IGNORE then in usbhid_parse:
> 
> 
>         quirks = usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
>                         le16_to_cpu(dev->descriptor.idProduct));
> 
>         if (quirks & HID_QUIRK_IGNORE)
>                 return -ENODEV;
> 
> and -ENODEV is -19 so it is no surprise you are getting -19 from
> hid_parse().
> 
> You need to make sure you are adding entry to
> 
> drivers/hid/hid-core.c:static const struct hid_device_id hid_blacklist[]
> 
> and not to
> 
> drivers/hid/usbhid/hid-quirks.c:static const struct hid_blacklist
> 
> Hmm, I wonder if we should rename the first one to something different,
> like hid_has_custom_driver. Jiri?

WHOA! Now we're cooking! My probe succeeds and now my
event/input_mapping/input_mapped functions all get called!

When driver developers are writing HID glue drivers like this, how is it
you generally determine the contents of your drv_data structure? Via
hardware specs or is there some way to poke at the device via USB and
have it tell you? Perhaps this question is a bit TOO out of line, as I'm
sure that information is available in the standard USB HID
information...