== DETAILS
After a bisect, the culprit was changing the gamepad interface from
returing a single button (bool) to multiple (int16).
The issue is that the Wii U gamepad (and presumably the Pro controller too)
have more than 16 buttons, which means some buttons get lost. Notably, L3 (18)
and R3 (17).
The solution: use int32 instead of int16.
I did a test build and confirmed that this change restores L3/R3 functionality
with the gamepad. Don't have a pro controller to test, but it should work too.
This change makes the call to 'udev_enumerate_scan_devices' much faster.
In particular, for some bluetooth devices, this function may implicitly
read its battery's virtual file 'uevent', e.g.
/sys/devices/*/usb1/1-1/*/bluetooth/hci0/*/power_supply/hid-*-battery/uevent
Reading this file may (for unknown reasons) block up to 10 seconds.
Since udev_enumerate_scan_devices is called 4 times (for keyboard,
mouse, touchpad, and joypad) during startup this may cause a
considerable delay.
Limiting the scan to subsystem 'input' yields the same devices but makes
the scan faster and does not read 'uevent' of the input controller's
power_supply.
* (PS2) added Multitap support (up to 8 players)
* (PS2) revert some identation changes
* (PS2) fix for non-analog controllers
* fix for not recognized digital and other non-standart controllers
* fixed ps2_joypad_destroy
Rumble was not working for me. I learnt a bit about how evdev works and it seems like you need to set a replay which defines how long the effect is (previously we set it to 0). This means there's a maximum length to the rumble effect which feels wrong.
When we do `play.value = !!strength;` we're setting the number of times for the effect to repeat, which works fine because the effect stops when we set it to 0.
It doesn't feel quite right to me playing e.g. Goldeneye but I've not played on real hardware for a while.
I'm hoping someone is more familiar with evdev and can suggest a better approach.
