On Tue, May 19, 2009 at 10:12 PM, Greg KH <greg at kroah.com> wrote: > On Tue, May 19, 2009 at 09:49:22PM -0700, Steven Hunt wrote: >> Hello list, >> >> I bought myself a super-cheap USB drawing tablet, and (shocker) >> there's no linux driver that supports it. > > What device is it? On the product packaging, it says "Hanvon Drawing Tablet"; however dmesg reports: HanWang co. HW Micro Drawing Tablet with a vendor ID of 0B57, and a product ID of 8019. Full output from 2.6.28-11-generic at device connect: [ 1673.776066] usb 2-2: new low speed USB device using uhci_hcd and address 5 [ 1673.961620] usb 2-2: configuration #1 chosen from 1 choice [ 1673.982901] generic-usb 0003:0B57:8019.0005: hiddev96,hidraw1: USB HID v1.00 Device [HanWang co. HW Micro Drawing Tablet] on usb-0000:00:1d.0-2/input0 > >> Using SnoopyPro, I was able to reverse-engineer the messages that get >> passed back and forth to the device, so I'm pretty sure I know exactly >> how the thing works. ?Given that information, how hard would it be to >> make a driver for it, or extend an existing one? > > It all depends on what type of data the device sends back. ?If it is a > HID device, it might be trivial. ?If it's a custom protocol, it's much > harder. I'm pretty sure that the device uses HID. On Windows, connecting the tablet causes two USB devices to show up, one of which is labelled "HID compatible device". The communication consists of some initialization messages (that seem to be state-independent), followed by a return of 8 bytes of data for each polling request. Snoopy reports that the functions that show up in the initialization messages are: GET_DESCRIPTOR_FROM_DEVICE, CONTROL_TRANSFER, SELECT_CONFIGURATION, CLASS_INTERFACE, and GET_DESCRIPTOR_FROM_INTERFACE while the main polling data is simply a BULK_OR_INTERRUPT_TRANSFER. I can't say I understand the contents of the init messages, but I do understand the 8 bytes that come back after each poll. Thanks for the quick reply! Steve
