So, first off, the fact that the puck doesn't show up as an independent device when streaming is intentional; the puck isn't technically a controller, so only the controller is exposed when streaming. (All Steam actually does with the Puck as an individual device separate from the controller is firmware updates, and allowing you to delete pairings from the record.)

If sharing the puck via VirtualHere fixes the issue, that means the *RPi* side is doing something wrong, but not that the Link needs to expose the puck to the host. All that would *actually* do is show the Puck entry for deleting pairings. Which there might be a use case for, but it wouldn't fix your issue.

Now, as for digging into the actual issue -- when you say the latency happens when the Controller is connected wirelessly to the Puck but doesn't happen when the Controller is connected to the Puck, do you mean that if you snap the Controller onto the Puck magnetically, the latency goes away, and if you remove it from the Puck it returns?

Also, as a side note, for the future there's a separate sub-forum for Raspberry Pi issues, separate even from the general Linux one since the RPi version of the Link client does have quite a bit of RPi-specific code. The General Discussion forum is kind of left over from the original hardware Steam Link box, back when it was the ONLY Link.

You can find it here: https://steamcommunity.com/app/353380/discussions/6/ (or go to the Discussions tab at the top of the page here, then pick Raspberry Pi on the sidebar)

Originally posted by Packetdancer:

So, first off, the fact that the puck doesn't show up as an independent device when streaming is intentional; the puck isn't technically a controller, so only the controller is exposed when streaming. (All Steam actually does with the Puck as an individual device separate from the controller is firmware updates, and allowing you to delete pairings from the record.)

If sharing the puck via VirtualHere fixes the issue, that means the *RPi* side is doing something wrong, but not that the Link needs to expose the puck to the host. All that would *actually* do is show the Puck entry for deleting pairings. Which there might be a use case for, but it wouldn't fix your issue.

Now, as for digging into the actual issue -- when you say the latency happens when the Controller is connected wirelessly to the Puck but doesn't happen when the Controller is connected to the Puck, do you mean that if you snap the Controller onto the Puck magnetically, the latency goes away, and if you remove it from the Puck it returns?

Thank you for the reply!

First of all let me say if I thought this was a RaspberryPi issue I would post in its specific forum, I think this is a Steam Link issue. I’ve had a very similar issue with other controllers before the app itself was updated to support them.

And yes! That’s exactly what I mean. When the controller isn’t magnetically connected to the puck the latency appears.

This is one of the reasons that leads me to believe the issue isn’t the Rpi, but rather the app itself.

If you go to Settings -> Controller and Test Controller in the Steam Link shell, before you start streaming, do you see the same latency? Also, can you provide any details on which RPi you're using, and which Pi Linux distro, etc.?

To elaborate, slouken and I have just run through tests and found one RPi setup that seems to have a bit of latency -- but we're seeing the *same* latency in the local controller test on RPi, without streaming in the mix at all. And it doesn't seem to matter if it's connected to the Puck or not.

(Which honestly is what I'd expect. The controller is still using wireless communication when magnetically attached and charging.)

Moreover, the code used for the Steam Controller on RPi is just accessing it via Linux hidraw, and on an Ubuntu box (also using hidraw), we don't see the latency at all, in either the local test or when streaming. *That* code is identical between the general Linux case and the RPi one.

Originally posted by Packetdancer:

Also, can you provide any details on which RPi you're using, and which Pi Linux distro, etc.?

Sorry, should've included this in my OP.



I'm connecting to a Windows 10 host.

Originally posted by Packetdancer:

To elaborate, slouken and I have just run through tests and found one RPi setup that seems to have a bit of latency -- but we're seeing the *same* latency in the local controller test on RPi, without streaming in the mix at all. And it doesn't seem to matter if it's connected to the Puck or not.

(Which honestly is what I'd expect. The controller is still using wireless communication when magnetically attached and charging.)

Moreover, the code used for the Steam Controller on RPi is just accessing it via Linux hidraw, and on an Ubuntu box (also using hidraw), we don't see the latency at all, in either the local test or when streaming. *That* code is identical between the general Linux case and the RPi one.

Yes, I was definitely wrong on controller magnetised to puck. The latency is exactly the same. Sorry about that!

While awaiting for a response here I opened a conversation with Steam Support and they suggested I move to the Steam Beta. I did as they said (and updated both puck and controller) and the behavior has now changed.

With wireless:
- I can start streaming
- The controller is recognised in "Settings -> Controller" as "Steam controller - Steam Controller Puck"
NOTE: This is different from when using VirtualHere. With VirtualHere I can see an entry for "Steam controller - Steam Controller Puck" as well as one for "Steam Controller Puck".
- Latency is undoubtedly present in-game

With wired:
- I can start streaming
- Controller does not appear in the controller list
- I cannot control anything

I'm as confused as you are at this point to be completely honest. This is on the current Steam Beta + Latest beta firmware for puck and controller (updates became available after rebooting into Steam Beta, so I assume they're beta firmwares!).

Originally posted by Packetdancer:

If you go to Settings -> Controller and Test Controller in the Steam Link shell, before you start streaming, do you see the same latency?

This is extremely hard to tell honestly. It's enough latency to be noticeable in an FPS, but it's difficult to tell on the test controller interface.

I'd say no, the latency isn't there. I think this makes sense considering the issue goes away in-game when using VirtualHere to share the Puck.

Strike the above, I connected another controller to compare and yes, you're right. I can see the latency in the Steam Link shell as well.

---------

I'd like to add that sometimes the Steam controller just isn't recognised at all by Steam and requires a host reboot for it to work. I can't seem to reproduce this consistently, but the controller won't show up in the "Settings -> Controller" list but still allow me to control the Steam interface.

In game the controller will not work at all.

I don't think this is related to the latency issue though!

Originally posted by cowpylon:

NOTE: This is different from when using VirtualHere. With VirtualHere I can see an entry for "Steam controller - Steam Controller Puck" as well as one for "Steam Controller Puck".

Originally posted by cowpylon:

I'd say no, the latency isn't there. I think this makes sense considering the issue goes away in-game when using VirtualHere to share the Puck.

Strike the above, I connected another controller to compare and yes, you're right. I can see the latency in the Steam Link shell as well.

To clarify a bit...

VirtualHere explicitly shares connected USB devices to the computer, pretending it's plugged in locally. This is why you see the Puck and the Controller as separate entries -- from Steam's standpoint, it looks like the Puck is plugged in physically and that's communicating to the Controller. So the difference in Puck appearing and Puck not appearing is expected, and entirely unrelated to any latency.

What slouken and I have seen in some testing is that on one of our Raspberry Pi devices here -- specifically an RPi 5, so that tracks with what you're seeing -- the Linux hidraw system (the part of Linux that lets you get at raw HID reports without needing a special driver) is just... slow with the Controller, at a system level. So the latency is also present in the shell's controller test, and even in things running locally using the Controller that aren't even directly related to Steam Link.

We're not sure *why*, since this isn't true on the other Raspberry Pi devices, nor on various desktop and laptop Linux boxes in general. But you seeing the latency in the controller test as well suggests that, yes, this matches your situation. (So, hey, on the plus side, that confirms we're seeing the same thing and know that what we look at here is likely to be the same problem you're seeing!)

The reason VirtualHere dodges the latency is that as soon as you start streaming, the host is seizing control of the USB devices via VirtualHere and skipping the hidraw layer entirely, just presenting it as an arbitrary USB device, so you're sidestepping all the local RPi-side code that actually thinks of it as a controller specifically (or even a HID device more generally) entirely.

(And thus sidestepping whatever's causing that lagginess for local access on the RPi.)

Anyway, we'll poke a bit more. And hopefully that helps clarify what we know so far!

Originally posted by Packetdancer:

To clarify a bit...

VirtualHere explicitly shares connected USB devices to the computer, pretending it's plugged in locally. This is why you see the Puck and the Controller as separate entries -- from Steam's standpoint, it looks like the Puck is plugged in physically and that's communicating to the Controller. So the difference in Puck appearing and Puck not appearing is expected, and entirely unrelated to any latency.

What slouken and I have seen in some testing is that on one of our Raspberry Pi devices here -- specifically an RPi 5, so that tracks with what you're seeing -- the Linux hidraw system (the part of Linux that lets you get at raw HID reports without needing a special driver) is just... slow with the Controller, at a system level. So the latency is also present in the shell's controller test, and even in things running locally using the Controller that aren't even directly related to Steam Link.

We're not sure *why*, since this isn't true on the other Raspberry Pi devices, nor on various desktop and laptop Linux boxes in general. But you seeing the latency in the controller test as well suggests that, yes, this matches your situation. (So, hey, on the plus side, that confirms we're seeing the same thing and know that what we look at here is likely to be the same problem you're seeing!)

The reason VirtualHere dodges the latency is that as soon as you start streaming, the host is seizing control of the USB devices via VirtualHere and skipping the hidraw layer entirely, just presenting it as an arbitrary USB device, so you're sidestepping all the local RPi-side code that actually thinks of it as a controller specifically (or even a HID device more generally) entirely.

(And thus sidestepping whatever's causing that lagginess for local access on the RPi.)

Anyway, we'll poke a bit more. And hopefully that helps clarify what we know so far!

I really appreciate the debugging and thank you for looking into it as much as you have!

Let me know if there’s anything you want me to try or if there’s any logs I can provide that could help.

I don’t mind trying different distros if that helps 👍

I'm having the exact same problem with the exact same specs. I've been using an 8bitdo as my daily driver with no problem so it's disheartening to see this issue with the shiny new controller I'd love to be using instead.

Oh, and thank y'all for poking around! I'm glad this is on someone's radar.

Update, for Raspberry PI 5, I believe PacketDancer found a fix - this resolves the issue for my configuration.

https://steamcommunity.com/app/353380/discussions/6/655981814410817132/?tscn=1780608840

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, you can download this script[www.libsdl.org] and run:

sudo bash set_polling_rate.sh 2

Amazing! Works perfectly!