* 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.
== DETAILS
The HID drivers in `input/connect/` were missing an implementation
for button(), so I added it. The only exception is the wii driver,
which is really complicated and more than I wanted to try to tackle--
especially since WIIU has its own wiimote drivers.
== DETAILS
When I first implemented the Wii U HID architecture, I ended up
having to design my own implementation because, at the time, I did
not have a way to read the HID device string to allow the existing
code to successfully detect the gamepad.
After spending some time experimenting, I've figured out how to
do this. And that means I can better align the HID driver with other
platforms.
change summary:
- create a single state structure for all three sub-types of wiiu pads
(kpad, wpad, and hid)
- eliminate confusing duplicate pad lists
- eliminate confusing duplicate HID pad drivers (ds3, gamecube
adapter, etc)
- ensure the ds3 driver still works
== DETAILS
I've created the concept of a hid_driver_instance_t which is basically
a central place to store the hid pad driver, hid subsystem driver,
the pad list, and the instance data for the above in a central location.
The HID pad device drivers can use it to perform HID operations in a
generic manner.
This is more-or-less a pause point so I can catch up with upstream.
== TESTING
Haven't tested this yet. Compiles without warnings though!
== DETAILS
The current HID implementation assumes a very low-level USB library
is being used. This causes a problem on Wii U, because the Cafe OS
only exposes a high-level interface.
To get these functions exposed to the HID pad drivers, I had to make
three changes:
1. I added the legacy "send_control" function to the HID driver
interface
2. I modified the signature of pad_connection_pad_init() to send the
driver pointer instead of the function pointer
3. I updated the HID pad drivers to keep the pointer to the driver
instead of the function pointer, and updated the calls into the
send_control function as appropriate
4. I updated the HID drivers to use the new pad init signature
== TESTING
Untested, in theory it should work without a hitch because at this
point all I've done is abstract things a little. I still need to
update the HID pad drivers to use the Wii U-specific calls as
appropriate.
In order to have a controller working you need:
1) Have a matching HID autoconfig file in autoconfig/hid for your controller.
2) Create a "connect" driver for the pad in "input/connect" folder (source code of RA).
3) Once you are in RA, change the joystick driver to HID and restart.
4) You may be now able to use you USB HID compatible pad in RA.
I included some "connect" drivers as an example. It also need to include them for compilation.
