== DETAILS
Looking at the other HID USB drivers, it looks like the typical
implementation is to start up a background thread to do the
polling, rather than wait for RA to invoke the poll() method.
This commit sets up the skeleton of the background thread:
- The thread gets created in init()
- The thread gets stopped in free()
Right now the body of the thread is a 10ms sleep.
== TESTING
It compiles cleanly, and links. Don't know if it actually works.
== DETAILS
I think I've about got the thread startup/teardown code worked
out. Logically, anyway, if not accurately.
The challenge has been figuring out how best to integrate the
features of HID2VPAD.
I found `input/connect/joypad_connection.c` and this seems like
the logical place for:
- Special-case driver for the Switch Pro controller
- Any other special cases HIDTOVPAD supports that core RetroArch
doesn't
- Parsing of HIDTOVPAD config file to add custom button mapping
== TESTING
Compiles. Haven't tested with a real Wii U. Probably doesn't work
though. I very likely have the threading bit wrong.
== DETAILS
Looking at the other HID USB drivers, it looks like the typical
implementation is to start up a background thread to do the
polling, rather than wait for RA to invoke the poll() method.
This commit sets up the skeleton of the background thread:
- The thread gets created in init()
- The thread gets stopped in free()
Right now the body of the thread is a 10ms sleep.
== TESTING
It compiles cleanly, and links. Don't know if it actually works.
== DETAILS
We discovered that the controller_patcher code was causing
the WiiU to intermittently crash when switching ROMs.
Changes:
- Completely extricates the controller_patcher code
- Create a skeleton wiiu_hid driver
- Wire up the build system to build/link it successfully
== TESTING
Has not been tested. Probably doesn't crash, since the
skeleton driver is just a copy of the null driver.
This commit has two main changes to the OSX HID driver:
1.
Some joysticks have invalid/incorrect 'use' assigned to buttons and
axes. For example, my RetroUSB.com Genesis Retroport reports 8 buttons,
but they're reported as 1, 2, 3, 4, 1, 2, 3, 4, and my RetroLink
Gamecube-clone controller reports 2 axes with id 50.
OSX assigns each of these elements a unique cookie value, so it's still
possible to uniquely identify a button. Whenever a controller is
connected, the driver scans for all buttons and axes. When it identifies
a duplicate 'use' id, it reassigns it a new ID.
Whenever the input callback is called, it grabs the cookie value,
finds the input element with a matching cookie, and uses that element's
id instead of the one reported by the device.
The old joystick configs should not be broken by this - I'm using the
existing 'use' value wherever possible, and only changing it when it's
broken.
The 'faked' ids are done in a deterministic way, a joystick will never
have a button's 'faked' id change between launches of RetroArch.
2.
This enables HAT switch input.
