* Added usb hid controllers for the famous ZeroDelay encoder and also for "Kade: Kick Ass Dynamic Encoder" to be able to use some custom arcade sticks.
* Add accidentally missing change to Makefile
Co-authored-by: DiktatorShadaloo <diktatorshadaloo@gmail.com>
* 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.
* (joypad_connection) Small optimizations -
* Turn functions static where possible
* Hose strlen call out of loop
* (input_driver.c) General cleanups:
* Some small code/style nits
task_screenshot.c:
* Move widget callback function for screenshots to task_screenshot.c
(file_path.c):
* Turn get_pathname_num_slashes into static function
* path_linked_list_free - always returns true, so get rid of return value
* path_linked_list_new - fix function signature
* path_get_archive_delim - do not NULL-terminate string, already done by strlcpy later on
General:
* Slight optimizations - use int/size_t for loop counter variable instead of unsigned
* Take advantage of fact that strlcpy already NULL-terminates, so don't do this explicitly
outside if we're just going to end up calling strlcpy/fill_pathname_join on it anyway
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 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
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
I fixed a similar bug in a past commit, with the same root cause: making
assumptions about the length of the array.
- Add validation to joypad_connection_init() so that if >MAX_USERS is
requested, a warning is logged and only MAX_USERS is allocated.
- Rewrote the iteration routines so they strictly use the
joypad_is_end_of_list() method to detect the end.
== DETAILS
- the free() method of the hid_driver_t interface needs its
parameter defined as const in order for the compiler to stop
complaining about losing const-ness.
- if a joypad list is created with <MAX_USERS slots in it, the
destroy() function will crash because it assumes there are MAX_USERS
entries.
To do this, the allocate function creates n+1 slots, and gives the
last slot a canary value that the destroy() method can then watch for
when iterating through the list.
== DETAILS
USB Vendor and Product IDs are in little-endian byte order, and they
need to be byteswapped on big-endian systems.
This approach allows us to use the standard hex notation for the VID/HID
values, and give them meaningful names, and only swap on the platforms
that need it. Also prevents having to abuse SWAP16() in the platform-
specific code.
== 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.
== DETAILS
- Added entrypoints into `input/connect/joypad_connection.c` to allow
a max value to be passed in, instead of using single macro value
- Created a hand-off between the HID attach handler and the worker thread
- Created a pad initializer in `wiiu_hid.c` leveraging the new functionality
added to `joypad_connection.c`
== TESTING
Compiles cleanly. At best, doesn't do anything. Might crash--not ready
to test quite yet.
On branch master
Changes to be committed:
modified: ../griffin/griffin.c
modified: ../input/connect/connect_ps2adapter.c
new file: ../input/connect/connect_psxadapter.c
modified: ../input/connect/joypad_connection.c
modified: ../input/connect/joypad_connection.h
