Well... the HID protocol is actually kinda nice.

[wolfwings]

Was able to make a small modification to the existing Sony-Quirks HID driver for Linux to replace the stock HID Report Descriptor (basically, the device describing it's own protocol format) with one that works a lot better for actual use. All the buttons that can, only report as analog now, the 5 digital-only buttons report in correctly as digital-only buttons, AND the accelerometer data is available though I have to tweak the HID Report Descriptor a bit more to make it work best still.

Next, tweak the cross-pad to show up as a single pair of axes instead of four, so it's more usable as a left/right and up/down input. Then just need to add some tunables to switch some inputs back to pure-digital, and look into some code to process the accelerometer and MEMS gyroscope into simpler translation/rotation inputs in the actual input driver itself.

Last will be getting rumble and LED-control working, but I'm already looking at having to actually retrofit the kernel HID drivers to support out-right replacement of the HID Report Descriptor instead of simple in-place modification. I'm not sure if that invasive of a change will fly or not...

Oh, and a quick link for anyone else curious about the actual HID protocol: The USB Implementers Forum's HID Development Page has a link to their HID Descriptor Tool, and above that links to all the various HID documents. HID's very easy to tinker with, I'm finding out.

Comments

[qdot.livejournal.com]

Yup, HID is great when done right. However, it's also pretty badly abused due to the fact that the windows HID manager lets you retrieve raw reports (linux and os x do not). Many devices use that fact to build crazy protocols on top of HID that actually don't work with the HID manager, but just to subvert having to install drivers on windows. Even though you can access raw USB from user space in linux and OS X, if you have one of these devices, you have to blacklist it in the HID manager first. So far, I've had two biometrics products do this:

http://qdot.github.com/libomron/
http://qdot.livejournal.com/224537.html

But yeah, if used for what it was meant for, it's fuckin' great. :3

Actually...

[wolfwings.livejournal.com]

...since 2.6.24 Linux does support accessing the raw HID reports. It's how others have made the SixAxis work is by processing the raw report in userspace. CONFIG_HIDRAW =^.^= Avoids having to detach the USB or Bluetooth device from it's normal protocol-stack, since the back-end HID stack just splits off a copy of the raw report for you to poke at. The previous post I made that included a PThreaded SixAxis interface uses that raw HID support actually.

And I may have to add another layer of Quirk-support, it looks like the PS3 is using the wrong byte-ordering for it's 10-bit accelerometers data, so I can't just say '16 bit field, 0-1023 logical range' successfully. There's a signed versus unsigned glitch in there too, will deal with that this morning now that I'm awake again.

Re: Actually...

[qdot.livejournal.com]

Oooh, thanks! I think the last time I'd even tried was 2.6.19 or some such. I'll have to try my lightstone and omron code soon and see if it works. :D

Re: Actually...

[wolfwings.livejournal.com]

Feel free to snargle the code I linked above, it's a decent attempt (I think) at making an async 'just go over here and process the data into something sane' middle-ware layer for dealing with raw HID reports at whatever rate the object returns them, seperate from the software that actually needs to use them. It was an excuse to learn PThreads, but after playing with the HID protocol it's actually rather close in idea, just without the report-descriptor stuff so it's device-specific.

I don't yet know the way to associate a HIDRAW with a USB device entry, mostly due to lack of research or any way to test it since I only have one device that will show up that way (my PS3 SixAxis/DS3) but that's a relatively minor limitation by comparison.

Also, most distro's don't pair up the HIDRAW's to have the same rights as the other Input devices, they stay in /dev/hidraw*, and are root:root by default still.