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
* features_cpu: Fix clock for djgpp
* frontend_dos_set_fork: Fix wrong id names
* dos_input: Fix missing indexing
* dos_joypad: Fix wrong id name
* Fix menu drawing
Menu is already prescaled to VGA_WIDTH x VGA_HEIGHT in vga_menu_frame. We need
to always use those dimensions
* Change dos compilation from griffin to common
* Set vga menu size to 320x200
* Add DOS compilation in gitlab-ci.yml
* Support for Swift, added emulator keyboard
* fixed toggle key handling using magic number hack for now
* fixed keyboard transparency slider for now with suboptimal fix; add gesture recognizer to hide/show keyboard
* Support CocoaView extensions in Swift; move keyboard delegate impl and setup to swift extension
* moved keyboard view model creation out of EmulatorKeyboard
* implement key pressed delegate in swift extension
* added input method for directly sending RETROK_* codes to support a touchscreen keyboard; assign keyboard model delegates; updated keyboard layout (added F1-F12 keys); change shift, control and alt keys to be modifiers
* enable focus mode when custom keyboard is shown; enable/disable overlay when custom keyboard is toggled
* Specify -DHAVE_OPENGLES2 instead of -DHAVE_OPENGLES3 since glsym_es3.h does not compile in iOS 14.5
Fix tvOS build using compiler flags
* Create new project for iOS 13 deploy target; add check for deploy target to conditionally compile for new iOS 13 specific feature (custom keyboard)
* force disable core info caching for iOS, use opengl es2 for debug
* Add flag for iOS custom keyboard - 3-finger swipe up to show, 3-finger swipe down to hide
* use OpenGLES2 instead; using ES3 results in compile time errors on iOS 14.5
* code cleanup
* Updated references to -DDONT_WANT_ARM_ASM_OPTIMIZATIONS flag
* Add JIT support for non-jailbroken devices
* iOS: Add support for touch mouse handler
* Added a HAVE_IOS_TOUCHMOUSE preprocessor macro so that it builds under the iOS11_Metal xcode project
* Changed click-and-drag behavior to double tap hold and drag
* Visual improvements to the emulator keyboard: updated colors, improved key-press effect
* Added newlib changes
* Add action to launch PPSSPP simulator
* Remove legacy config for the stack and heap
* Add pthread
* Simplify kernel_functions and improve references to HAVE_KERNEL_PRX
* Add some flags
* Improve audio init/deinit
* Improve exit by clicking home
* Add CI for PSP1
* Update PSP.yml
* Fixes mouse-grab toggling in Wayland.
Fixes#13536
* Indicate that input_wl_grab_mouse is a necessary function.
It might prevent it from being removed again in future cleanups.
