Feature request: Lower the input lag for button inputs

[jueank]

I know, this is primarily a feature request for the Pinscape Firmware, and only indirectly a feature request for the PinscapeConfigTool.

Recently, some measurements were carried out in the community to determine the input lag of various controller boards. Among others were the KL25Z and newer representatives such as Arnoz RP2040 based ‘Dude's Cab’.
The results were:

• KL25Z: 9.8 ms
• Pinone: ~4 ms
• Dude's cab: <1ms

This software & hardware has been used:
https://inputlag.science/
A video from Arnoz is available here:
https://www.youtube.com/watch?v=Df8dQ7WSZCY&t=13s
And there is a short discussion here:
https://discord.com/channels/652274650524418078/1225490311007043716/1273003391513002034

9.8ms for KL25Z is close to the 16.6ms for a full frame (at 60 fps), i.e. it's a relevant value in practice (imho). I.e. the response time for the player could be affected. And it's worth using every opportunity to reduce the input lag (again: imho).

Arnoz has implemented a very short input lag for favourite functions in its firmware (5 inputs: pinball, magnasave plus another one)
I am totally satisfied with my KL25Z & Pinscape and the Pinscape software. You have really created something great here! I am also a supporter of open source software & hardware.
Therefore: It would be great if you could reduce the input lag in the Pinscape firmware as well!

[mjrgh]

You can set the device side's HID wait time in the config tool. The default setting is 8.33ms, so I suspect that the video you're referencing was using default settings. If you want to get lower numbers from the test rig, all you have to do is set the HID wait time to, say, 0.5 ms in the config tool.

However, that would probably be detrimental to performance on an actual PC, because the actual HID polling rate is determined by the Windows HID driver, and is typically set to around 8 to 10ms. It's not up to a device when to send a HID report; it's up to the PC to ASK for one. If you configure the KL25Z to try to send HID reports every 0.5ms, you'll just force it to spend 8-10ms on every cycle burning up time waiting for the PC to ask for the next report. The HID pacing setting in the Pinscape configuration is meant to let the firmware keep doing other work between reports. You're better off setting the reporting interval on the device to match the polling interval on your PC, to maximize time available for other tasks, thus the 8.33ms default.

In their wisdom, Microsoft didn't expose the HID polling rate as a user-configurable setting. Probably because they believe that messing with it will affect other aspects of system performance without any material benefit, so exposing it would just misguide users into messing with something that couldn't possibly do them any good to mess with. However, I've heard of "hack" tools that let you mess with the HID driver to change the polling rate, which some gamers use because they believe that "faster is better" without limit, even though the standard setting was chosen to be comfortably below the human threshold of perception. If you're really concerned about latency, what you'd want to do is install one of those tools to reduce the HID polling rate on the PC, and change the Pinscape setting to match. I'm not personally convinced you'd see any net improvement in the playing experience with Windows games, because they tend to have a lot of other input layers between the raw USB input and the video output that I'm pretty sure will dominate; i.e., the standard 8ms cycle is probably already faster than they really need to achieve their best possible input response time performance.

If you're interested enough, I'd encourage you to set up the test rig you referenced and test my claim above about the effect of changing the Pinscape parameter. The firmware internally samples the physical buttons on a 1ms cycle, so if you adjust the reporting rate to a comparable interval, I expect you'd see ~1ms latency on the reports. But it would be interesting to find out if that holds up experimentally.

[jueank]

@mjrgh Thank you very much for your detailed answer!
To my understanding, the two cycles (KL25Z HID wait time and Windows HID polling rate) are not synchronised, right? This means that in the worst case they will nearly fully add up.
Example:

• At first, the button we want to observe is not pressed
• The KL25Z checks the button state and waits 8.33ms (HID wait time) until the next report
• 0.01ms later the user presses the button
• 8.32ms later (shortly before the 8.33ms HID wait time expires), Windows queries the HID report from the KL25Z (button is reported as not pressed)
• Windows waits 8 - 10ms until the next HID polling; only then the button will be identified as being pressed
  This means that the maximum input delay could be as much as ~18.32ms. Following this logic, it would be advantageous to set the KL25Z HID wait time as short as possible.

Something I don't understand:
"If you configure the KL25Z to try to send HID reports every 0.5ms, you'll just force it to spend 8-10ms on every cycle burning up time waiting for the PC to ask for the next report."
From what you wrote elsewhere, the windows driver is asking for HID reports on USB devices. I'm a bit confused here... Is both happening?

In your second paragraph you wrote that a too short HID wait time would be ‘detrimental’ to the performance on an actual PC and that the firmware should do other work during the HID wait time.
I'm asking, not because I want to question what yo wrote, but I would like to understand what you mean exactly. Is that a general statement, or do you know other tasks of the KL25Z that will be slowed down or become unreliable when the HID wait time is too low?

Maybe I'm lacking the true understanding, what the HID wait time really is. But when you say that the firmware samples the physical buttons every 1ms, why can't you just dynamically invalidate the current / fixed HID wait time when the state of a button changes? Meaning: you generate the HID report exactly when a state change is detected.

[mjrgh]

You should just look at the code if you want to understand what's going on at that level of detail. Your notion of the loop is completely different from what's in the code, so you're drawing a bunch of conclusions from it that don't follow from the actual code. I think if you look at the code you'll understand why I reached the different conclusions I laid out in the earlier note.

And I'd really recommend running the actual experiment if you want to verify one way or the other.