* Add grab_mouse interface for Android
Makes mouse grabbing and 'Game Focus' work on Android with a real mouse
Properly handle relative mouse motion events on Android (SDK 28 and newer)
* Enable workflow_dispatch on CI Android
* Update android_mouse_calculate_deltas callsites
* Add RETRO_DEVICE_MOUSE to android_input_get_capabilities
* Use Handler to trigger UI events (toggle mouse, immersive mode) with 300ms delay
* Enable input_auto_mouse_grab by default for Android
* Handle RARCH_DEVICE_MOUSE_SCREEN in Android input driver
* Add android.hardware.type.pc to manifest
* Don't attempt to set pointer speed via scaling in android_mouse_calculate_deltas
* Keep x/y values within viewport resolution for screen mouse
* Use video_driver_get_size to get width/height
---------
Co-authored-by: Bernhard Schelling <14200249+schellingb@users.noreply.github.com>
When running on Android, RetroArch considers most devices that emit dpad events as gamepads, even if they also emit other keyboard events; this is usually the right thing to do, but it has the side effect of not letting some actual keyboards (e.g.: Logitech K480) act as such inside RetroArch. This configuration option allows users to manually select a specific input device to act as a physical keyboard instead of a gamepad, which is handy when emulating computers as opposed to consoles.
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
Closes https://github.com/libretro/RetroArch/issues/3414
I have investigated the issue. The crux of the problem is that on Android there
is no way distinguishing 2 scenarios:
1) 2 identical bluetooth controllers A and B and first there are button presses
only on controller A and then on controller B
2) the same controller disconnects and reconnects.
Android doesn't give bluetooth mac address of where the touch came from, only
opaque ID and this opaque ID changes after reconnect. Hence without changes to
android this is infeasible without giving up the ability for 2 users to play on
identical controllers.
I guess that this sacrifice makes sense for affected users
* 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
