For the mayflash N64 adapter, I was getting a BAD EXC ADDRESS (in mac OS 10.13) for this line (tmp was NULL). Retroarch would crash in the gui if I pressed a button from the DPAD on controller 2. With this change, it no longer crashes in the gui and still registers the button push.
For my Xbox One Controller the min input for the hat is 1 and not 0. 0
points to the default state that is called after each button press.
On top of that the two axis for the trigger buttons were ignored. I
added some additional axis that are not present on my controller but
will probably help for other input devices.
=== DETAILS
Replaced includes for things that aren't standard library headers so
they use quotes instead of brackets.
Also fixed up a couple of headers that had include-order dependencies.
=== DETAILS
Since @aliaspider wants the `wiiu/` to be something of a mini-SDK, I've
reorganized the code I put in there:
- `wiiu/main.c` now only has the ELF/RPX entrypoints, and the code used
by those entrypoints, with RA code removed (e.g. swapped retro_sleep()
for usleep()). These entrypoints then call main() ...
- Moved `main()` and its support functions back into `frontend/drivers/platform_wiiu.c`
I also renamed some of the support functions I wrote, and better
organized them within the code.
- Moved `wiiu/input/` into the `input/` hierarchy:
* The joypad drivers now live in `input/drivers_joypad/wiiu/`
* The HID driver now lives in `input/drivers_hid/`
* The Wii U specific headers now live in `input/include/wiiu`
* I added `input/include` into the include search path to avoid
using really ugly relative includes
== DETAILS
Now that I have a working implementation, it's time to tidy up a bit:
- there was no need for the HID subsystem's object data to have a reference
to the global hid state (since it's global), so removed it.
- refactored the users of that member to use the global state, defining
reusable macros.
- reorganized the information in *.h files
- removing the hid state also made the constructor changes to the hid driver
unneeded, so I reverted those changes.
== TESTING
Confirmed clean build. Haven't tested the build yet to make sure everything
still works, though.
== 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
RetroArch's general HID drivers are intended as a full-on substitute for
other input drivers such as XInput, DInput, SDL, etc. The Wii U port is,
to my knowledge, the first case of heterogenous input drivers working
concurrently.
As such, I've moved things around:
- The HID driver source is moved into the wiiu/input/ directory alongside
the joypad subdrivers.
- We no longer use the input_hid_init_first() method to instantiate; instead
we just init the wiiu HID driver directly.
- The HID pad driver and HID subsystem driver enjoy a tighter coupling,
mainly having to do with the initialization of the joypad connections
list, because there's no way to inform the HID driver's init() method
how many slots to allocate.
== TESTING
Will test in a moment, but at least it compiles cleanly. ;)
== 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
Well, after a lot of code analysis, this seems like the
best way to handle things on the Wii U without also completely
re-architecting the I/O handling in RetroArch.
How it works:
- the top-level wiiu_joypad driver is now nothing more than a
delegator.
- the wiiu-specific drivers live in `wiiu/input/`
- wpad_driver.c handles the WiiU gamepad
- kpad_driver.c handles the wiimotes
- hidpad_driver.c will handle HID devices like the GC adapter, DS3/DS4, etc.
(I say "will" because this isn't implemented yet)
== TESTING
Haven't actually tried the build to see if it works, but it does
compile.
== 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
I haven't figured out how I'm going to get the data read via HIDRead()
funneled back to the adapter--the handle_packet() method doesn't actually
get called anywhere.
I'm probably going to need to do more tweaking to the function pointer
list.
This commit also adds logging for the data read via HIDRead.
== TESTING
I used my "stress test" (which I used to reproduce the crash caused
by the old HID implementation), and it did not crash.
== DETAILS
Starting to implement the I/O handling on the HID driver.
The old implementation basically had a never-ending HIDRead() callback
set up, so that callback N would start the read process for invocation
N+1.
We will take the same approach here; but now that the I/O thread is
happenning on its own core, we should be able to let it run full-
throttle without impacting emulator performance.
Of course, this hinges on the callback actually running on the same
core as the syscall was initiated on.
== TESTING
Can confirm that the read_loop_callback gets invoked on the same core
that the HIDRead() was invoked on.
== DETAILS
This implements the WiiU-specific functions.
Since the wiiu_hid_t data structure contains the handle and interface
index, the method signatures can be simplified quite a bit. And since
(at least for now) we want these to be synchronous, we don't need to
expose the callback parameters.
== DETAIL
One minor detail missed in the last commit: actually putting the
send_control function into the driver declaration. Woops.
Not doing the Wii U because it will be using the other methods.
== 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.
== DETAILS
After wasting some cycles trying to isolate a crash, I went back to
basics.
I enabled the network logging, and put in a bunch of logging lines,
and noticed that the HID thread wasn't actually starting.
I did quite a bit of experimenting, working with different
memory alignments, and finally got it working.
== TESTING
As you can see, I put a log output inside the worker thread. When
I run the build, I can see the TICK messages. I can also see that
the thread shuts down as expected.
Also! The HID callback works as expected too! I have the GC
adapter, and when I register the HID callback it fires and I get the
following data:
[INFO] USB device attach event
[INFO] handle: 2058729
[INFO] physical_device_inst: 0
[INFO] vid: 0x7e05
[INFO] pid: 0x3703
[INFO] interface_index: 0
[INFO] sub_class: 0
[INFO] protocol: 0
[INFO] max_packet_size_rx: 37
[INFO] max_packet_size_tx: 5
Note that these are raw dumps of the data passed to the method,
so e.g. the VID/PID might be byte-swapped from how they're usually
represented.
Have not done the stress test to try to reproduce the crash.
== DETAILS
The old code was crashing; I did a minimalized branch and the crash
went away, so I'm bringing that over here. Meaning I'll have to
redo some of the other work I'd put in, but oh well.
(now watch it start crashing again)
== TESTING
Can confirm it builds. Wii U is busy ATM so I can't test.
== DETAILS
I did a minimalist edit of the HID thread that stripped out all
HID* syscalls, and this stopped the crashing. I then re-added just
the HIDSetup() and HIDTeardown() calls, and the crash came back.
This smells like an OS bug. To work around it, I've put the
HIDSetup() and HIDTeardown() calls into the app init/shutdown
section, so they only get called once in the application lifetime
and not each time the input driver is initialized.
== 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
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.
twinaphex