Set All Controls via touch screen does not prompt the user to set D-Pad up

[davidhedlund]

Description

Single-touch interactions on the touch screen function as an "OK" button within RetroArch's interface. Users often rely on this touch functionality to access and activate the "Set All Controls" option, which is crucial for configuring gamepad controls. This touch screen capability is particularly significant because there's no guarantee that the "OK" button will work properly on the gamepad's fallback profile. Without a functioning "OK" button on the gamepad, it could be impossible to activate "Set All Controls" using the controller alone. Therefore, the touch screen serves as a critical backup method to ensure users can access and initiate the gamepad configuration process, even when faced with potential limitations in the fallback profile.

However, when you activate Set All Controls via the touch screen, it does not prompt the user to set D-Pad up:

Platform	Input Method to press "OK" to set Set All Controls	Prompts for D-Pad Up	Notes
RetroArch Android	Touch Screen	No
RetroArch Android	Gamepad button (fallback profile)	Yes
RetroArch Android	Gamepad touch screen activation button (fallback profile)	Yes
RetroArch Android	Bluetooth Mouse	N/A	Mouse activation doesn't work
RetroArch Desktop (GNU/Linux)	Touch Screen	Unknown	Not tested. Does quick tap source code exist in other releases than Android? If so, then someone with a touch screen could help us.
RetroArch Desktop (GNU/Linux)	Gamepad button (fallback profile)	Yes
RetroArch Android (GNU/Linux)	Gamepad touch screen activation button (fallback profile)	Yes
RetroArch Desktop (GNU/Linux)	Bluetooth Mouse	Yes

Expected behavior

Users should be prompted to press D-Pad up, just like they are for the other controls.

Actual behavior

D-Pad up is automatically assigned to Mouse 1, and the prompts continue with D-Pad down, D-Pad left, D-Pad right, etc.

Steps to reproduce the bug

1. Navigate to Settings -> Input -> RetroPad Binds -> Port 1 Controls.
2. Tap on Set All Controls using your finger (do not use any gamepad button to activate it).

Version/Commit

You can find this information under Information/System Information:

• RetroArch: 1.17.0 for Android from retroarch.com

Environment information

[davidhedlund]

• Set All Controls: Analog L2/R2 issues for udev and linuxraw, but not sdl2 #16767

[zoltanvb]

Reproduced on Android both with glui and ozone (so probably not menu driver dependent). Does not happen on desktop when mouse click is used to activate "Set all controls".

[zoltanvb]

Bit of a tricky issue. My current assumption after some time of checking the code, is that the quick tap function, which is reported by the android input driver as mouse button left, but only once, and either this is misinterpreted, or the pointer un-press event gets reported separately. In any case, the left mouse button will get immediately assigned to the bind (first bind, D-pad Up in case of bind all, or to the single bind if that was used), without having to hold anything. No solution yet, the code is a bit complex around here.

[i30817]

btw, I often wish this menu had a way to set the interval for the keys recognition of set all controls higher. It's a bit easy to miss one and ruin a config especially if you have motor problems or some kind of arthrosis.

[davidhedlund]

btw, I often wish this menu had a way to set the interval for the keys recognition of set all controls higher. It's a bit easy to miss one and ruin a config especially if you have motor problems or some kind of arthrosis.

• Thanks. In order to keep this issue free from distraction, can you please file a feature request for that and link it here?
• I've filed a bug report regarding the short interval in Android for Set All Controls, please comment or vote for it in order to bring more attention to it: RetroArch 1.17.0 for Android: Remap regression bugs #16217

[davidhedlund]

Bit of a tricky issue. My current assumption after some time of checking the code, is that the quick tap function

Thank you for taking your time.

Current hypothesis
After examining the code, the initial assumption is that the quick tap function may be the source of the issue.

Proposed testing strategy
To isolate the problem, it's crucial to determine if the touch screen issue is specific to mobile platforms or if it also affects desktop versions of RetroArch.

Desktop verification attempt
An attempt by me was made to test the desktop version using VNC, but this proved inconclusive:

• The quick tap function was unresponsive on the phone when used as a VNC client.
• Double-tapping .txt files in ~/Desktop/ failed to open them.
• This prevented using the phone as a touchpad to interact with RetroArch installed on the GNU/Linux system.

Next steps
To effectively troubleshoot:

1. Test RetroArch directly on a desktop system with touch capabilities, if available.
2. Compare behavior across different RetroArch versions on mobile devices.
3. Investigate if the issue is related to specific cores or is present across all RetroArch functionality.
4. Engage someone with a touch screen that can be used for GNU/Linux on a desktop computer, or a mobile device that runs a GNU/Linux distribution (not Android) to further assess the issue.

By systematically testing across platforms and configurations, we can better isolate whether the quick tap function is indeed the root cause of the touch screen problems in RetroArch.

[davidhedlund]

quick tap

Could you please check if there is any source code related to quick tap in RetroArch releases other than Android, such as for GNU/Linux? If such code exists, we need someone to reproduce this issue using a touch screen on the desktop versions. If it does not exist, then we can rule out that this is an Android issue.

[zoltanvb]

After digging around a bit more, setting Bind Hold to a non-zero value will allow bind to function normally with a touchscreen as well. I am tempted to set bind hold default to 1 in case of Android builds as a workaround. Earlier PRs mention some problem, but it seems those are fixed already: #15909 #16256

Udev input driver may have similar input for tap, but it is unclear whether that also exhibits this problem or not.