mirror of
https://github.com/libretro/RetroArch.git
synced 2026-11-12 18:45:33 -10:00
c6046da20f
* Android: read the input queue on a thread of its own Android sends a window its next key only once the window has finished the last one, and a NativeActivity gets every key twice: before the IME, marked AKEY_EVENT_FLAG_PREDISPATCH, and after it. Read on the main thread once a frame, with the first copy finished unhandled for the IME, each key took two polls, about 30 keys a second at 60 Hz. A pad mashed faster than that queued up in the system, and its presses kept arriving seconds after it was let go. A thread with its own looper now reads the queue. It copies each event into an SPSC ring and finishes it at once, so Android sends the next one straight away. The copy before the IME is the one read, unless the system keyboard is open, when keys still go by the IME first. Volume keys are left to the system and read once, after the IME. Until the first input driver starts, events are finished unread. With the ring full, the reader leaves events in the queue until the poll makes room. The poll applies the copies in order through the same handlers. A key, a finger or a mouse button can now go down and back up between two polls, so the poll stops at the first event that would undo what an earlier one did in the same poll and leaves the rest for the next (android_poll_changes.h): a press shorter than a frame is still seen for one. Mouse moves in one poll are summed. The reader answers APP_CMD_INPUT_CHANGED once it has let go of the old queue. The AMotionEvent calls looked up with dlsym are looked up once, before the reader starts, since it reads them too. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01YTBjv1trXRxAXvNwCt89Ka * Android input reader: records of their own size, read where they lie Each event went through the input reader's ring as a 312-byte record, whatever it was, built on the reader's stack, copied into the ring and copied out again by the poll. A key needs 44 bytes of it and a stick's move 88. A record is now as long as its event: a key ends before the stick axes, a stick's move before the touch fields, and a touch, mouse or pen carries only the pointers it has. The reader builds each where the poll will read it, and the poll applies it there (android_input_ring.h); nothing is copied after the event leaves the input queue. A record never crosses the ring's end: the rest of a lap is a pad the poll steps over. The ring is 64 KiB, some 1500 keys. A stick's moves are its state: the poll keeps only the last of a frame. The reader publishes what it writes once the queue is empty, and a stick's move written over its unpublished move before it, as long as the hat stays where it was, so a fast pad no longer fills the ring and holds back keys behind it. A hat, the D-pad of many pads, tapped between two polls was lost: the poll's hold-back covered keys, fingers and mouse buttons only. Its four directions are kept back the same way now. android_input_ring_test holds the ring to reading in place, records whole across laps, merging only unpublished moves, and two threads; android_poll_changes_test has a hat lane. --------- Co-authored-by: Claude Opus 5.5 <[email protected]> Co-authored-by: LibretroAdmin <[email protected]>