ANDROID S-Pen stylus support

[f4mrfaux]

Description

This PR delivers a proper, end-to-end Samsung S Pen implementation on Android that
uses the RetroArch RETRO_DEVICE_POINTER API correctly. It separates hover/drag
from click semantics, adds settings + i18n + docs, and fixes the root causes behind
prior rejections of earlier approaches.

What this PR does

• Implements hover + barrel (side) button drag that maintains an active pointer
  (pointer_count > 0) so RETRO_DEVICE_POINTER_* queries behave as expected.
• Correctly recognizes both AMOTION_EVENT_BUTTON_STYLUS_PRIMARY and
  AMOTION_EVENT_BUTTON_STYLUS_SECONDARY (pens vary by device).
• Makes hover-drag independent of the “Require contact for click” policy.
  (Clicks still follow the contact path; hover never synthesizes clicks.)
• Adds three user settings with full menu + i18n wiring and maintainer docs.

Why this succeeds where earlier attempts were rejected

• Uses the official RetroArch pointer input path (RETRO_DEVICE_POINTER)
  instead of ad-hoc mouse/touch emulation.
• Avoids conflating hover with contact: hover only maintains a drag pointer
  while the side button is held; click generation remains in the contact (ACTION_DOWN/UP) path.
• Ensures a live pointer is maintained during side-button hover-drag, fixing the
  [PtrQuery] count=0 failure mode seen previously.
• Ships with settings, labels, help text, and documentation so behavior is explicit,
  discoverable, and testable across devices.

Files changed

• input/drivers/android_input.c — S Pen hover-drag logic; proper pointer maintenance; PRIMARY/SECONDARY support
• configuration.c, configuration.h, config.def.h — settings parse/struct/defaults
• intl/msg_hash_us.h, intl/msg_hash_lbl.h, msg_hash.h — strings & hashes
• menu/cbs/menu_cbs_sublabel.c, menu/menu_displaylist.c, menu/menu_setting.c — menu wiring & help text
• docs/S-Pen-Implementation.md — maintainer documentation & test plan

User-facing settings

• Require contact for click (on/off) — unchanged click policy
• Allow hover drag with side button (on/off)
• Move cursor on hover (on/off)

Testing summary

• Device: Samsung Galaxy Z Fold5 + S Pen (Android 14 / One UI 6.x)
• Before: hover + side-button drag → [PtrQuery] count=0
• After: hold barrel button while hovering → one synthetic pointer “down”,
  continuous “move”, release ends pointer; [PtrQuery] count=1 while dragging.
• Toggling Require contact for click has no effect on hover-drag (by design).
• Menu navigation and in-core pointer routing unaffected.

Related Issues

• Closes [Android] RetroArch Doesn't Ignore S Pen Hover Actions #15490 — S Pen hover input previously conflated with touch/mouse; no maintained pointer during drag.
• Closes [Feature Request] <S pen support for mouse / Lightgun> #18194 — Proper S Pen interaction on Android using the correct RetroArch pointer path.

Related Pull Requests

• Supersedes / follows up: Fix issue #15490 #15597
  This PR addresses the review concerns that prevented merging earlier work:
  it uses RETRO_DEVICE_POINTER correctly, keeps hover separate from clicks,
  handles both stylus button bits, and includes settings + i18n + docs.

Rationale & Implementation Notes

• Hover handler reads button state once and treats the barrel button as pressed
  if PRIMARY or SECONDARY is set.
• While pressed, a maintained pointer is started/updated/ended; this is independent
  of the contact-click policy to avoid disabling hover-drag when Require contact
  is enabled.
• Contact path (ACTION_DOWN/UP) is unchanged and continues to govern clicks.

Backwards Compatibility & Risk

• Low risk: Click semantics unchanged; feature is settings-gated.
• Scope: Android only (android_input.c) and UI/i18n plumbing.
• Performance: No measurable impact (same event cadence/paths).

Documentation

See docs/S-Pen-Implementation.md for configuration guidance, device notes,
and a step-by-step validation checklist (with sample debug log lines).

Attribution

• Thanks @ETJeanMachine for the original report in [Android] RetroArch Doesn't Ignore S Pen Hover Actions #15490. :contentReference[oaicite:3]{index=3}
• Thanks @xlab for the foundational S-Pen refactor & button support in Fix issue #15490 #15597. :contentReference[oaicite:4]{index=4}

Reviewers

Android/input maintainers and collaborators:

• @gouchi
• @sonninnos

(Feel free to add/remove preferred reviewers.)

[f4mrfaux]

one thing im noticing on additional testing:
mag cases CAN still mess up sensitivity. works on my machine (lol) but i just sent the build over to a friend who has a different brand magnetic case and it clearly wipes out stylus input in the exact O- key pattern of the mag case. I will try to add a sensitivity slider or something but might just be "one of those things"

[zoltanvb]

Thank you for taking the effort. Preliminary comments:

• config.def.h, readme.md, androidmanifest.xml, version.all changes should be removed from the PR
• android.mk change should probably also not be put to master

[f4mrfaux]

Thank you for helping me polish my PRs so they meet standards, and doing so, so politely. I will re-submit with your suggested changes thank you for the valuable feedback. Thanks.

…

On Tue, Aug 26, 2025, 2:09 PM zoltanvb ***@***.***> wrote: *zoltanvb* left a comment (libretro/RetroArch#18201) <#18201 (comment)> Thank you for taking the effort. Preliminary comments: - config.def.h, readme.md, androidmanifest.xml, version.all changes should be removed from the PR - android.mk change should probably also not be put to master — Reply to this email directly, view it on GitHub <#18201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIDANIC5OROW6UYEHVZCJAD3PSPHPAVCNFSM6AAAAACEXWTIZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMRVGIYDMMRWGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[sonninnos]

It also needs a rebase, since as-is it will remove my latest recently merged changes regarding menu toggle.

[f4mrfaux]

Cleanup done — I’ve removed all changes to config.def.h, README.md, version.all, AndroidManifest.xml, and Android.mk.
PR now only includes Android input + settings + i18n + docs. Ready for re-review.

[f4mrfaux]

It also needs a rebase, since as-is it will remove my latest recently merged changes regarding menu toggle.

AAAARG! ty, will do.

[f4mrfaux]

@sonninnos @zoltanvb Rebased onto latest master and preserved the recently merged menu-toggle changes.
Removed all changes to config.def.h, README.md, version.all, AndroidManifest.xml, and Android.mk.
PR now only includes Android input + settings + i18n + docs for stylus/pointer.
Ready for re-review — thanks!

[zoltanvb]

I checked it on my device (no S-Pen, so just for regression) and seems to behave OK. But then again, I built the change that was causing problem earlier, and it was also working on this device, so this is not a particularly good test.
If someone has a device which exhibits the previous issue ( one list in #15597, other list in #15672 (comment) ), it would be better to test on that as well. The revert commit (c72f861) shows that the problem was probably how those devices reported events.

[f4mrfaux]

I checked it on my device (no S-Pen, so just for regression) and seems to behave OK. But then again, I built the change that was causing problem earlier, and it was also working on this device, so this is not a particularly good test. If someone has a device which exhibits the previous issue ( one list in #15597, other list in #15672 (comment) ), it would be better to test on that as well. The revert commit (c72f861) shows that the problem was probably how those devices reported events.

for what its worth I have HW tested it on a dell NASHER360 that has been loaded with trixie>waydroid

[LibretroAdmin]

I checked it on my device (no S-Pen, so just for regression) and seems to behave OK. But then again, I built the change that was causing problem earlier, and it was also working on this device, so this is not a particularly good test. If someone has a device which exhibits the previous issue ( one list in #15597, other list in #15672 (comment) ), it would be better to test on that as well. The revert commit (c72f861) shows that the problem was probably how those devices reported events.

Let me know I guess when the person who had the previous issue has tested the latest PR build here and reports no more issues

[f4mrfaux]

...If someone has a device which exhibits the previous issue ( one list in #15597, other list in #15672 (comment) ), it would be better to test on that as well. The revert commit (c72f861) shows that the problem was probably how those devices reported events.

I can confirm on native hardware that issue has been resolved or at least "works on my machine". I can post logs as receipt. I had thatissue when I first implemented using xtabs method without knowing it.
US variant z fold 5 and OE stylus. the pressure sensitivity may need adjusting based on the pen model and if you have a mag case or not but I feel like I found a happy medium

[zoltanvb]

I was able to validate one scenario on my device. When connecting a controller, the old build (1.16.0) exhibited the problem, neither the controller worked nor the touchscreen. I am glad to say that this does not happen with this change, touchscreen and controller continues to work as before, so I have no more objections.

[zoltanvb]

Combining this condition with the previous one, the remaining part of the code could stay as it is, reducing the diff.

[zoltanvb]

Please do not put this behind ifdef. This log writing is related to a recent change by me and would like to see it in logs in case someone reports a problem.

[f4mrfaux]

will do, thanks for your patience, and feedback as we get this ball down the field

[f4mrfaux]

did HW testing with new implimentation. snes9x is much better, but stylus support is a less polished experience on the menu.
"I want you to put my groceries in one bag so its easier for me to carry to the car, but I dont want it to be too heavy"

[LibretroAdmin]

Let me know if you want me to merge this now or if you want to hold off further.

[f4mrfaux]

Please hold off I found a bug right before leaving on vacation and I'm just getting back into cell range :) thank you!

…

On Mon, Sep 1, 2025, 10:22 AM LibretroAdmin ***@***.***> wrote: *LibretroAdmin* left a comment (libretro/RetroArch#18201) <#18201 (comment)> Let me know if you want me to merge this now or if you want to hold off further. — Reply to this email directly, view it on GitHub <#18201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIDANIFHXAUWKUDTPMJLAZL3QRJARAVCNFSM6AAAAACEXWTIZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBSGU3DANZXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[LibretroAdmin]

Alright, thanks

[f4mrfaux]

oof.

[LibretroAdmin]

Hi, there seem to be some build failures now with the latest commit

[LibretroAdmin]

There are some other issues with this: the Pokemon-branded files in here do not belong in RetroArch or in this PR.
strcasestr should not really be used, it's not portable. Use libretro-common equivalents instead.
I think honestly you should split this PR up into two. One that adds the basic S-Pen functionality and then a second PR that touches all these separate files like cheat_manager and whatnot. As it is this is kind of an omnibus PR and it's pretty hard tracking down issues that can arise from PRs with such PRs in the long run

[f4mrfaux]

There are some other issues with this: the Pokemon-branded files in here do not belong in RetroArch or in this PR. strcasestr should not really be used, it's not portable. Use libretro-common equivalents instead. I think honestly you should split this PR up into two. One that adds the basic S-Pen functionality and then a second PR that touches all these separate files like cheat_manager and whatnot. As it is this is kind of an omnibus PR and it's pretty hard tracking down issues that can arise from PRs with such PRs in the long run

I totally agree I have two different features Im working on, and accidentally mixed my unified feature testing branch. this is a huge learning experience for me working with version control, and github branching. I sincerely apologize I got lost on what branch I was working in and got sloppy.

apologies again.