link pi subforum
https://steamcommunity.com/app/353380/discussions/6/

I am also seeing this latency :(

We've managed to reproduce it here on RPi as well. It looks like it might be an issue in hidraw (the thing that lets userspace programs have access to HID devices on Linux) on RPi when talking to the new Controller, but we're not sure what's happening there yet.

It is being looked at, though, and hopefully we'll have a fix soon.

Until there's a fix, using VirtualHere should function as a workaround if you have it; VirtualHere seizes things at a base USB level (not just HID) and shares them to the host PC, so bypasses hidraw (and whatever's going on there on RPi) entirely.

I think I've tracked down what's going on. It looks like the RPi is using the (rather restrictive) default polling intervals for mouse and keyboard for the Controller, due to the controller first enumerating as a mouse/keyboard (e.g. lizard mode). When the controller shifts to controller mode, the RPi is still retaining that rather restrictive poll rate.

The RPi tends to keep the polling rate low so that it can be low power -- which makes sense -- but in this case it's a problem, as it forces the Controller (which wants to send updates potentially every 4ms) into sending updates only as fast as the RPi wants to handle a keyboard (which is every 16ms).

To test my theory, could one or both of the folks seeing this latency edit /boot/firmware/cmdline.txt for your RPi and add the following onto the end of the line:

usbhid.mousepoll=1 usbhid.kbpoll=1

...to allow polling intervals as short as 1ms for keyboard/mouse. After you've edited the file, reboot and try the controller again. In my testing, that lets the Controller properly use the 4ms polling interval it expects.

Wow! Incredible! I believe this fixed it - I don't notice any perceivable latency at all, this feels exactly as responsive as my other test controllers now. Thank y'all so much for investigating this issue, I can use my new favorite controller now :)

Originally posted by Homsar:

Wow! Incredible! I believe this fixed it - I don't notice any perceivable latency at all, this feels exactly as responsive as my other test controllers now. Thank y'all so much for investigating this issue, I can use my new favorite controller now :)

Glad that works!

For those who run into this before the next update, instead of modifying the kernel command line, you can download this script[www.libsdl.org] and run:

Originally posted by slouken:

For those who run into this before the next update, instead of modifying the kernel command line

To add to this -- those who have changed the cmdline.txt can also change it back and use this script before running Steam Link if they want. The script will change the polling rate for *just* the Steam Controller. Which is nicer on the poor Pi than my initial nuclear option fix of all mice and keyboards was.

Otherwise, as slouken's post implies, the next update to the RPi package will contain this script, so will automatically set an appropriate polling rate. :)