Controllers with same VID/PID are distinguished by the device name.
1. The Wii U only sends a prefix of the device name.
2. The check preferred the device name over VID/PID which was not
intended.
Example: The device name "USB Gamepad" is truncated to "USB" which
was mapped to "Generic SNES USB Controller", although VID/PID did not
match.
Otherwise autoconfig file can't be found on the Wii U:
VID/PID are not available, so it has to match with 'input_device' and I
don't want to add additional autoconfig files with different
'input_device' strings.
Otherwise the USB gamepad cannot be found, if VID/PID has leading zero.
For example: Retrode gamepad adapter:
vid=1027 (0x403) pid=38849 (0x97c1) becomes
vid=1027 (0x403) pid=-26687 (0xffff97c1)
== DETAILS
The crashes he reported in the gbatemp thread are due to iface
being null (since it's an unsupported device) and unchecked
iface dereferences.
== DETAILS
Put the finishing touches on getting the DS3 to work on Mac OSX.
Basically, there's some differences in the HID interface bewtween
wiiu and osx where OSX expects the first byte of the report to be
the report ID, while wiiu expects that byte to be trimmed off.
I was able to put this behavior in the respective HID
implementations, which eliminated the confusing packet offset
ifdefs.
And, I was able to get the LEDs working again.
== DETAILS
The DS3 driver previously only worked with the Wii U HID implementation.
I adapted this driver from the Linux driver for the DS3. It's not quite
100%--I haven't got the LEDs to work properly--but it's functional.
Going to continue tweaking it to see if I can get the LEDs to work.
== DETAILS
- rewrote the HID deregistration algorithm; it should no longer
cause issues when dealing with multiple pads of the same HID/VID
combo
- fix initialization bug that caused wiimotes to fail to register
without an accessory attached
== DETAILS
The GCA uses a weird HID class that our current filters don't
catch, so we add it.
Needed to do a small amount of tweaking on the GCA driver to
account for iohidmanager weirdness.
== 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
Use a little trickery to ensure the GCA driver continues working
with other HID implementation.
I've expanded the joypad implementation to support multi-pad devices.
However, this requires changes to each HID implementation to actually
function.
I've made the necessary changes for WIIU, but I don't have the means
of making the change in the other HID implementations.
So, I've built in a backwards-compatibilty mode for the driver.
The trick is to have an identifier byte at the top of both data structs
that the driver returns. We can then use that byte to determine which
of the structs has been passed to the pad functions and act accordingly.
In the GCA case, for non-wiiu platforms, it will simply expose port 1
of the GCA and the other 3 ports do nothing.
== DETAILS
cause of crash: trying to deference init when it's null
the reason it was going into deregister: the HID/VID lookup was
failing because it wasn't getting initialized first
cause of 2nd crash: the "end of pad list" method looked for an entry
with a magic value, so we add an end marker
== DETAILS
I'm going to need to re-implement the abstraction between HID device
and gamepad; the changes here lay down some foundation for that work.
- reduce logging priority of some statements I modified while debugging
- factor out the pad driver lookup into its own method
- fix so the pad driver list isn't re-initialized every invocation
- add the button() method for the GCA driver
== 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
After a bisect, the culprit was changing the gamepad interface from
returing a single button (bool) to multiple (int16).
The issue is that the Wii U gamepad (and presumably the Pro controller too)
have more than 16 buttons, which means some buttons get lost. Notably, L3 (18)
and R3 (17).
The solution: use int32 instead of int16.
I did a test build and confirmed that this change restores L3/R3 functionality
with the gamepad. Don't have a pro controller to test, but it should work too.
== DETAILS
Hooray for conditional compile directives.
Moving things around broke things in unexpected ways on non-WiiU builds.
Well, not *completely* unexpected. But still.
Changes:
- Move some typedefs around to avoid circular include dependencies
- Include the file where the HID driver definition got moved to
== TESTING
- verified build for Wii U still runs successfully
- did a local build without any errors (some weird warnings, but since they
happen in code I didn't change, I'm assuming they're pre-existing?)
== DETAILS
- Added a new method to the joypad_connection_t interface for
getting a single button
- wired everything into the hidpad driver
- for testing purposes, hacking the top-level joypad driver
so that kpad isn't used
- add a new RARCH_LOG_BUFFER method to verbosity for logging the
contents of a binary buffer (useful for writing/debugging pad drivers)
- fix a few bugs in the wiiu GC pad driver
The button mapping isn't quite right, and I'm not sure what's
going wrong.
