This is a proof of concept for the fallback path without pkg-config.
As jack is something often not installed by default it demonstrates
that when pkg-config exists and the dependency doesn't the check_val
function in qb/qb.libs.sh will redundantly check -ljack and as expected,
fail. It also shows that when pkg-config is not installed and jack is
enabled with --enable-jack it will bail and print a configure error.
This accomplishes two things for the fallback path without pkg-config.
1. If --disable-foo is passed to configure it will explicitly skip
check_val. This has the benefit of reducing checks in
qb/config.libs.sh which are easy to break due to human error.
2. When a fallback path exists and --enable-foo is passed to configure,
but fails due to the missing -lfoo check_val will now bail and print
a configure error. However --enable-foo will still be ignored if
there is no fallback path and pkg-config is not installed.
One issue with this is that if pkg-config is installed and the package
foo is not, it will still check if -lfoo works. As not all pkg-config
implemenations can be trusted to work even if they exist this seems
unavoidable.
== 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 gamepad didn't work because I had tried to rename the pad from
'WIIU Gamepad' to 'WiiU Gamepad'.
I added some debug logging and (to cut out a lot of trial-and-error)
discovered that the reason it didn't work was because a bug in a macro
was using the define literally instead of substituting it (so e.g.
the autodetect handler was trying to match 'WiiU Gamepad' against the
literal string 'PAD_NAME_WIIU_GAMEPAD').
- Fixed the macro bug
- Left a minimal amount of the debug logging in place; may come in
handy for someone else.
- Updated wpad/kpad/hidpad to use the define constants
== TESTING
Did a test build and confirmed the gamepad responded.
