* Input: Udev: Fix touch support building against older kernel headers
* Input: Udev: Fix Touch Deep Debug compile issues
* Input: Joypad: Udev: Joypad: Add Change detection for udev events
This is handy with controllers like the Nintendo Joycons that have a daemon
app in the background to handle combining them into one controller(Joycond)
Since the device was already added, but joycond clamped permissions on evdev
retroarch was never updating the controller input change, this fixes that issue.
Note: Needs a patch in joycond as well, to send change uevent.
This shouldnt cause any issues with other controllers, as the kernel probably
will never send change events for these device types.
* Lakka: Add canary builds to updater
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.
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.
The current code get the USB vendor/product controller, in case of
bluetooth connection this means that you get the bluetooth dongle ids
instead of gamepads. This is not fine as we match gamepads using their
product and vendor ids.
Credits go to SDL which helped me to figure out this issue.
http://hg.libsdl.org/SDL/file/f7c6b974d5af/src/joystick/linux/SDL_sysjoystick.c#l208
GavinDarkglider