libretro / libretro/RetroArch

[Android] RetroArch Doesn't Ignore S Pen Hover Actions

Open
#15,490 17 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

platform: android
Dominant language
C
Stars
14.1k
Forks
2.2k
Avg merge
7h 35m
Merged PRs (30d)
51

Description

Description

RetroArch seemingly makes no distinction between S Pen hover actions and mouse actions, resulting in S Pen functionality within RetroArch being inaccurate.

Expected behavior

When using the S Pen on a supported device (e.g., Galaxy Note Series up to Note 20, Galaxy S Series for S21 Ultra and up, etc.), hovering should do nothing (or move an unseen cursor exactly to where the S Pen is hovering over), and tapping the screen should act identical to using a finger.

Actual behavior

The S Pen hover action moves an unseen cursor on screen that starts at an unknown point to the user, and following taps from the user are registered at the point where the unseen cursor is, rather than where the S Pen actually is tapping on screen.

Steps to reproduce the bug
  1. Use a S Pen supporting Samsung device
  2. Go into Samsungs settings and enable Advanced Settings > S Pen > Air view > Previews and pointer
  3. Open a game with the MelonDS core
  4. Open MelonDS's core options and enable Screen > Touch Mode > Mouse
  5. Observe failed behaviour of black cursor vs S Pen location

It is worth noting the bug does not just occur within MelonDS, as it persists throughout the entire UI. MelonDS just offers the best way of visualising how the bug is happening.

Visual produced via MelonDS

Here you can see the S Pen's location (as a hovering action) in actual space be indicated by the white arrow. The black square pixels is where the "unseen" cursor actually is within the emulator. The cursor will register clicks when the user taps the screen (indicated by the white arrow turning into a circle), but not at where the S Pen actually is, and instead only at wherever the black pixels are.

To clarify, the S Pen is never touching the screen in this example except for when the cursor lights up in a circle.

https://github.com/libretro/RetroArch/assets/54557728/7d76da31-07c1-4596-b241-87de618831a4

Additional Notes

Searching through the repository, I can see that stylus support was added in Version 1.7.7. I am unsure if the backend that Samsung uses for stylus's is different than Android core's. I also note that in Android's input drivers, there is a line to exclude stylus input, and to only include touch/mouse input.

https://github.com/libretro/RetroArch/blob/62e4779fee8aaa29a0fc216a79b5f4d5d13f6061/input/drivers/android_input.c#L1418-L1422

Nothing seems to indicate within RetroArch that I have a mouse connected but, nevertheless, the S Pen seems to roughly act as how one would expect a mouse to operate. My rough guess is here that the S Pen's backend is different than other stylus backend on Android, and that it misses this else/if, and gets interpreted as a mouse. That's just my guess as to what's happening however, I am unfamiliar with both the backend for stylus input and s pen input on Android.

Version/Commit
  • RetroArch: 1581ece
Environment information
  • OS: Android 13, One UI 5.1
  • Device: Note 20 Ultra (SM-N986U1)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with input/drivers/android_input.c around lines 1418-1422, then reproduce on the Note 20 Ultra with Android 13, Air view enabled, and MelonDS Touch Mode set to Mouse. Compare hover and tap handling across the RetroArch UI. Done means S Pen hovering no longer causes an unseen mouse cursor, while screen taps register at the actual touch location.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, c
Domain
mobile-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.