hidapi_steamdeck: severe input lag if vsync enabled

[jorio]

hidapi_steamdeck: severe input lag if vsync enabled

[mmmaisel]

I can reproduce this issue with the testgamecontroller app on the Steam Deck with Gnome and both Wayland and X11.
In my test, I got an input latency of about 1 second.

I also patched the SDL_hidapi_steamdeck driver so it tries to drain the buffer, see this branch. However, this did not fix the issue so I guess there is something else causing the issue outside of the driver.

[slouken]

@mmmaisel, can you take a look?

[mmmaisel]

I had a quick look at the source code without doing some real tests and noted the following things:

• Once initialized, the HIDAPI driver only talks to the device when the function HIDAPI_DriverSteamDeck_UpdateDevice is called by SDL.
• The driver itself is independent of vsync and other graphics code. Actually, it does not even know if vsync is enabled or not.

With this information, I have the following untested theory:

There is some synchronization issue that delays the calls to HIDAPI_DriverSteamDeck_UpdateDevice when synchronizing to the screen which takes about 16 ms at 60 Hz. In the meantime, the HIDAPI fills data in a buffer much faster every 1-4 milliseconds so the next call to the HIDAPI_DriverSteamDeck_UpdateDevice processes some outdated data. Depending on the HIDAPI buffer size, the accumulated outdated data then causes input lag of about half a second.

When the HIDAPI driver is disabled by the SDL_SetHint, a kernel driver is used instead which always present up to date data to userspace when asked without buffering old values.

[mmmaisel]

@jorio, Can you please try if my steamdeck-drain-buffer branch fixes your problem?

In my tests with the testgamecontroller utility, it fixes the latency issue on the Steam Deck.

[slouken]

Oh yes, reading from the controller should definitely be done in a loop, like is done with all the other HIDAPI controllers.

[slouken]

That explains why it's related to framerate, since it's only reading one report every time through the frame loop.

[jorio]

@mmmaisel Sorry - it took me a while to get around to testing this. Can confirm that I can't perceive any more input lag. Thanks a lot!