[nzlug] USB reverse engineering

[Robin Sheat]

I have a USB DJ control device that I want to make work fully in Linux. It 
half-works as an HID device, so I know that it's possible. However, I'd like 
to make a libusb driver for it.

When as an HID device, input from the buttons and sliders etc. comes in just 
fine, however it's not possible to set any but one of the LEDs (I don't know 
why only one, when I send the commands for any of the other ones, no USB 
traffic occurs. I suspect something fishy in the HID part of the kernel, 
apparently this used to work in 2.4).

The problem is that when talking to it via USB, I can only make the LEDs work 
(haven't actually tried this yet, but some related software can do it), I 
can't figure out how to make it tell me of changes to the state of the 
buttons and so on on the controller. My guess is that you send it something 
that puts it in the right mode to send data back, but I don't know what that 
is.

Using usbmon ( http://people.redhat.com/zaitcev/linux/ ) I see this when using 
it via HID:

f01f19c0 0.375157 S Ii:1:008:1 -:-606348325 20 <
f01f19c0 0.376219 C Ii:1:008:1 -2:-606348325 0
f01f19c0 0.376696 S Ii:1:008:1 -:-606348325 20 <
f01f19c0 0.377215 C Ii:1:008:1 -2:-606348325 0
f01f19c0 0.379778 S Ii:1:008:1 -:-606348325 20 <
f01f19c0 0.387210 C Ii:1:008:1 0:-606348325 20 = 01000000 90787d7d a37b7a82 
ffff0000 00008080
f01f19c0 0.387251 S Ii:1:008:1 -:-606348325 20 <
f01f19c0 0.395216 C Ii:1:008:1 0:-606348325 20 = 01000000 90787d7d a37b7a82 
ffff0000 00008080

the long packets provide the state of all the controls, and this is what I 
want to get via libusb. However, if I'm reading it right, nothing gets sent 
which would put it into this state (I think the 'i' means input, data coming 
from the device). 

When reading from it using libusb, I get nothing until I send some zeros at 
it, and then it just gives me meaningless data (that's me talking to it in in 
the 'Co' parts, and then the last 2 lines repeat as fast as I want to read 
them):

dd5f1ba0 0.840041 S Co:1:010:0 s 01 0b 0000 0000 0000 0
dd5f1ba0 0.841696 C Co:1:010:0 0 0
f01f10c0 0.843695 C Ii:1:010:2 -108:-606348325 0
f01f1ba0 0.844202 S Co:1:010:0 s 01 0b 0000 0001 0000 0
f01f1ba0 0.844692 C Co:1:010:0 0 0
f01f1ba0 0.845363 S Co:1:010:0 s 21 09 0201 0000 0010 16 = 00000000 00000000 
00000000 00000000
f01f1ba0 0.845691 C Co:1:010:0 0 16 >
f01f1ba0 1.845795 S Ii:1:010:1 -:-606348325 64 <
f01f1ba0 1.864667 C Ii:1:010:1 -84:-606348325 0
f01f10c0 2.864748 S Ii:1:010:1 -:-606348325 64 <
f01f10c0 2.888638 C Ii:1:010:1 -84:-606348325 0
....

What magic does the kernel do to make it start talking that I'm missing out 
on? (In case you haven't guessed, I'm pretty new to programming USB stuff)

-- 
Robin <robin at kallisti.net.nz> JabberID: <eythian at jabber.kallisti.net.nz>

Hostes alienigeni me abduxerunt. Qui annus est?

PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8  7175 14D3 6485 A99C EB6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.linux.net.nz/pipermail/nzlug/attachments/20071209/ec020aba/attachment.pgp