== 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.
== DETAILS
The handshake stuff is derived from the old HID2VPAD, just in knowing
what data goes in what report.
- Added the HID_REPORT_ flags to syshid.h
- Renamed the generic "REPORT_TYPE" flags to be meaningful
- also fixed incorrect parameter list for set_protocol
== TESTING
The functions aren't implemented in wiiu_hid.c just yet,
so this is gonna crash if you try to run it.
== 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
Looking at the apple input driver gave me an idea--moving the
HID driver into the wiiu_input_t data instead of piggy-backing
it off the wiiu_joypad driver.
- Remove changes to wiiu_joypad
- Add equivalent to wiiu_input
This is probably broke as hell. Haven't tried to compile.
== 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.
As discussed in libretro#5357; controller_patcher is now optional. It's
off by default; though this could be changed with a simple makefile
tweak (ENABLE_CONTROLLER_PATCHER ?= 1, perhaps?)
To re-enable controller_patcher; append ENABLE_CONTROLLER_PATCHER=1 to
your usual make command.
controller_patcher was the only user of c++ constructors in the Wii U
port, so you'll need 26a006c in your tree otherwise you will have a
blackscreen on startup.
Oops! Didn't do this quite right the first time round.
This commit fixes RETRO_DEVICE_ID_POINTER_PRESSED, which would always
return 0 due to to an implicit case to int16_t. Basically, we'd do
(val & 0x00080000) & 0xFFFF; which would return 0 every time. Fixed that
by wrapping it in a ternary. Yes, I know we could use a rotation, but
for a boolean value it really doesn't matter.
I also rewrote scaleTP to deal entirely in integers. While the
floating-point math was theoretically faster on PowerPC; it gets awkward
to cast -0x7FFF to a float.
Speaking of, the driver now actually conforms to the libretro API. Not
sure how I managed to not see the spec; but hey, now its fixed.
RETRO_DEVICE_POINTER_ID_X/Y will now return values between -0x7FFF and
0x7FFF like they're supposed to.
Big thanks to @r-type for hounding me to fix this.
Partially addresses #5294; we still need mouse emulation.
This hopefully fixes the issues when you try to use 2 Controllers with
the same vid/pid at the same time.
Tested with 2 DS4 controller via the Hid to VPAD Network Client.
Adapters with multiple ports (like the official GC-Adapter) are still
working
Allow using the Gamepad's touch screen as a RETRO_DEVICE_POINTER.
Methodology could use some work, had to add an extra axis to
joypad in order to get the data transferred into the input driver.
Feel free to change this.
Needs to emulate RETRO_DEVICE_LIGHTGUN to really be useful.
Potential for Wiimote IR in future.
Partially addresses libretro/RetroArch#5294
input_overlay_add_inputs added, still need to implement dpad and analog visuals on overlay. Also still needs to be restructured so input_overlay_post_poll is only called once.
* the remote control presents itself as ID_INPUT_KEY, not
ID_INPUT_KEYBOARD. However, ID_INPUT_KEYBOARD is a subset of
ID_INPUT_KEY.
* the remote control lacks the backspace and enter keys, which are hard
coded in RetroArch. It has "back" and "ok" instead, so map those to
RETROK_BACKSPACE and RETROK_ENTER as well.
Remote controls also have no ESC key, but that one is customizable
and I used the Power key of the remote (which already has a mapping
to RETROK_POWER).
The functionality provided is really the bare minimum, but it is enough
to teach a kid "press the power button here to watch TV"; compared to
pressing L1+R1+START+SELECT and navigating to the RetroArch's "quit"
menu item, that hopefully has more chances of success.
* the remote control presents itself as ID_INPUT_KEY, not
ID_INPUT_KEYBOARD. However, ID_INPUT_KEYBOARD is a subset of
ID_INPUT_KEY.
* the remote control lacks the backspace and enter keys, which are hard
coded in RetroArch. It has "back" and "ok" instead, so map those to
RETROK_BACKSPACE and RETROK_ENTER as well.
Remote controls also have no ESC key, but that one is customizable
and I used the Power key of the remote (which already has a mapping
to RETROK_POWER).
The functionality provided is really the bare minimum, but it is enough
to teach a kid "press the power button here to watch TV"; compared to
pressing L1+R1+START+SELECT and navigating to the RetroArch's "quit"
menu item, that hopefully has more chances of success.
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
gblues