Adapt the sanitized pointer handling, discussed at libretro#17196 :
winraw and dinput driver specific changes:
make sure pointer position is always within [-0x7fff,0x7fff] by using the confined wrapper
remove extra "inside" checks, general simplification
enable pointer offscreen reporting
use common functions for edge detection and lightgun button ID conversion
sdl driver specific changes:
pointer handling aligned with the other input drivers, as above
added TODO for lightgun part - no suitable test env at the moment where SDL input can be used
* First crack at light sensor support for Linux
* Add light-sensor support to most Linux input drivers
* Fix a compiler error
- Whoops, forgot to declare `sdl`
* Refactor linux_illuminance_sensor_t
- Allow the poll rate to be specified
- Poll the sensor on a separate thread
- Open a file handle each time we poll the sensor, since sysfs doesn't update the contents of an existing handle
* Set the `done` flag when closing the light sensor
- Whoops
* Avoid a division by zero when updating the poll rate of an existing sensor
* Don't try to open illuminance sensors from ".", "..", or hidden files
* Never mind
* Fix some silly mistakes
* Skip hidden files, ".", and ".."
* Cancel the sensor poll thread mid-sleep when closing it
- POSIX says it's fine
* Add to CHANGES.md
* Address feedback given on PR
* Use libretro-common's file system instead of stdio
- Add missing numlock mod to dinput
- Add missing scrolllock mod to x11
- Add missing capslock, numlock, scrolllock and meta mods to android
- Add missing scrolllock mod to sdl
- Add missing capslock, numlock, scrolllock and meta mods to switch
- Add missing numlock mod to winraw
- Add missing numlock mod to uwp
Repurpose vibrate_on_keypress to enable device's standard keypress feedback on overlay key/button state changes
- Add keypress_vibrate function ptr to input_driver_t (only implemented on Android for now)
- (Android) Remove APP_CMD_VIBRATE_KEYPRESS
- (Android) Add doHapticFeedback, called directly to avoid latency
* Any pad can control the menu
== DETAILS
I am not sure I've quite got it so that any pad can *open* the
menu, but I do have it so any pad can control it.
- split out the input processing into a separate method
- track down and squish some hairy bugs that boiled down to
bad pointer math
- it looks like `menu_driver.c` has a mix of line endings, so I
ran it through `dos2unix` so it has consistent line endings
again.
- verified that this change did not impact actual cores
* optimize out cumulative_bits
* Incorporate PR feedback
Many thanks to @jdgleaver for providing these optimizations.
* apply one more optimization
