Amusingly, it's one of the Dual Shock 3's for a PS3, running cabled over USB for now until I find time to sort out why the Bluez stack is so braindumb when it comes to HID devices since 3.x. I understand making something depreciated, but when it's the version people still prefer to use because it Just Works I don't frankly care how much nicer the newer codebase is, if it still doesn't work for many things the older codebase did.
Upside? Learning how to add a patch to an ebuild via overlays on Gentoo at least.
Tinkering with the actual device, I'm running into another oddity... the HID reports the device is sending back have all the information in them such as the accelerometer and gyroscope measurements, but ARGH the main input-device results are almost unusable they're so cluttered, having an axis AND a button-event for the majority of the inputs on the device. =-.-=
Is it wrong that I've written (in the last 60 minutes) a POSIX-threaded triple-buffered and fully asynchronous framework for dealing with the HIDRAW values for this device? I'm not sure if it's just a coding-toy for myself, or if I want to look into actually making this into an actual userspace joystick driver to better support the PS3 controllers akin to the XBoxDrv system. I'm leaning more towards the latter, and I'm wondering if I should expose the accelerometers in their naked XYZR, or pre-process into something like yaw, pitch, and roll.
Though I am happy that the core monitoring routine for the device is just a poll() call, minimal 'did we get a full report?' test, and a decode followed by a lock/update/unlock. The actual mutex-locked update is only 'copy two pointers' so it's vert fine-grained, and the client-side update routine is also the lock/update/unlock sequence. The naked decode routine can be used if needed, as well.Leave a comment