Increase polling rate of the RP6 (and others) builtin controller to 250hz - #12
Open
diogotr7 wants to merge 1 commit into
Open
Increase polling rate of the RP6 (and others) builtin controller to 250hz#12diogotr7 wants to merge 1 commit into
diogotr7 wants to merge 1 commit into
Conversation
Change the hardcoded SET_PAR report-period byte from 0x07 to 0x02 in the rsinput init command, raising the default gamepad polling rate from ~111 Hz (9 ms) to ~250 Hz (4 ms) for all rsinput devices. Empirically the MCU reports on whole-ms intervals: rate ~= 1000/(period+2), so 0x07 -> 111 Hz and 0x02 -> 250 Hz. Verified lossless on a Retroid Pocket 6 (0 dropped frames at 250 Hz; UART ~50% utilised at 115200 baud). NOTE: this is a blanket default change affecting every rsinput device (AYN Odin 2 family, Ayaneo Pocket EVO, etc.), only hardware-validated on the RP6. For a per-board / opt-in approach see the report_period param + DT property branch instead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The byte changed is
SET_PARon other implementations of the same device, and from my research it tells the MCU of the built-in gamepad how long to wait between each poll. the time it waits isN+2ms. The old value, 7, results in a 9ms wait, which gives 1000/9=~111hz. Changing it to 2 results in a 4ms wait time, resulting in 250hz polling. Lower values do not work properly, as for some UART driver reasons the reports get batched for some reason and instead of getting e.g. 500hz atSET_PARof1, we instead get half a second worth of reports at once, instead of continuously. very strange.Tested and works fine on my RP6, but of course the change affects other devices, which i have not tested.
Advantage of this polling rate increase comes mostly from being 2x the refresh rate (on 120hz devices). This reduces input latency because, since we poll twice per frame, every rendered frame will have fresh data to use, instead of running behind.
In practice, it's not particularly noticeable but it seems like a free improvement :D
AI use: Claude Code was used to diagnose the low polling rate, and a fix was tested and implemented. The initial patch it came up with lives here: https://github.com/virtudude/armada-packages/compare/main...diogotr7:armada-packages:rsinput-streaming-rx-parser