* Fix Sixaxis gamepad operation
== DETAILS
It looks like commit 78e7d23c144c862d65ae1bf7ee41a1228bdfa380 broke
the DualShock. Sorry, @revvv, but this is probably going to break the
Retrode driver. We'll need to figure out a different solution.
* Fix a bunch of HID implementations
== DETAILS
As mentioned in the previous commit, the thing that broke the DS3
driver was a change to the wiiu HID handler, which did some pointer
math on the data buffer.
The thing is.. there's no reason to do that pointer math. Yet, I found
the same thing on almost every other HID driver: OSX, libusb, wiiusb.
The only other HID driver that did not do this was the Bluetooth
HID driver.
It doesn't make any sense. The only reason it doesn't crash is because
the memory right before the buffer is valid memory.
Change summary:
- remove the weird pointer math from all HID controllers
- remove the `#ifdef apple ...` in the ds3 and gamecube adapter
drivers, because it's no longer needed.
- in the pad packet handlers, decrement data buffer offset references
to account for the removal of the buffer manipulation.
* Fix DualShock 4
== DETAILS
Should've only subtracted 1, not 2; and now the pad works.
Also, added a PID to cover newer model DS4s. I picked "R2" out of the air
for the constant.
Tested on Mac OS
* Really really fix iohidmanager_set_report
A huge apology to @23rd for insulting your fix. I was wrong to call you
wrong.
That left the question: why did that change break the DS3?
Well, it's because `IOHIDDeviceSetReport` expects the report buffer to be
just the report. All of RA's HID SetReport calls include the report number
in the first byte, so we have to trim that off.
We actually do this in a different invocation of `IOHIDDeviceSetReport`
elsewhere in the file! This commit applies that same logic to
`iohidmanager_set_report`
This has two benefits:
1. The DS3 works
2. The DS3 no longer requres the user to press the PS button to activate
it the first time. You plug it in and it Just Works, just like on Wii U.
