* 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 78e7d23c14 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.
* MacOS: Fix sixaxis on MacOS 12.x
== DETAILS
Mac OS 12.x "Monterey" dropped some built-in support for the
Sixaxis controller--exactly what changed is unclear, but other
projects reported similar issues with the OS.
This commit ports the work done on SDL, which is basically to
read two feature reports after writing out the activation report.
I think we did this at one point in the past, but it got lost
among HID driver rewrites.
I've tested this locally and it resolves the issue; after connecting
the sixaxis and pressing the Playstation button, the pad is registered
and works successfully.
I have not tested this on other platforms.
* Gracefully handle incomplete HID implementations
== DETAILS
Not all HID drivers implement all HID methods; since this controller
has a magic sequence that requires the ability to set and get HID
reports, we need to make sure we don't crash if we're running on
an incomplete implementation.
- Add a null check for the driver methods and log useful info if checks
fail
- Fix minor formatting
* (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 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)