can't seem to record or screenshot it

In case you haven't already tried this... if you launch SteamVR from the command-line with VRLINK_DUMP_BISTREAM=1, does the issue show up in the resulting /tmp/vrlink_debug.h265 file? That'll at least help figure out if it's a problem in the encoding itself or not.

Ooh, I did not know about this. It looks like encoding is fine when I play the file in VLC (no weird jitters or resolution changes). Must be a bug on the Quest 3 side of things... but my attempts to capture the bug on my Quest 3 have fallen short. Definitely some funky client bug.

Excellent, that helps narrow it down. Thank you!

Question -- just to make sure we're on the same page, when you say it jitters around, do you mean that it looks like the foveated part is being composited slightly offset from the proper location?

It's like the resolution of the foveated part goes back and forth. You don't have to move your head to see it.

Okay, I've managed to reproduce this. That is definitely weird, but now that I have a setup that presents the error we should be able to track it down.

FWIW, I'm now almost positive this is in the Quest bug (and not something weird in the metadata being sent from the host side). I'm going to leave it tracked by this ticket because I have better luck consistently reproducing this on Linux than on Windows for some reason, but I can reproduce it on both.

Yeah, that definitely tracks. Probably why it never shows in quest screenshots or recordings.

WELL. OKAY. I've found what's happening.

• When in a high resolution, each frame takes longer (understandably).
• When in a high refresh mode, bandwidth usage is higher and it's easier to miss frames (also understandably).
• Quest's Adaptive SpaceWarp appears to have been forced on globally in the latest OS, whether or not an app supports it.
• When a frame arrives late, Quest is trying to apply spacewarping to it.
• Adaptive SpaceWarp will (by design) only adjust the bottom-most layer.
• Steam VRLink in foveated mode will draw the background in one layer and the foveated part in a second one.

Thus, the behavior we're seeing here. Turning on the stats overlay on the Quest, you can even watch the ASW FPS graph spike upwards in direct correlation with how bad the wibbly effect is.

I've got a band-aid solution, at least.

That doesn't quite explain why this practically goes away when I hit 90hz or less in SteamVR. Because the stream is still 120hz until SteamVR restart. Is there some other thing that is set right away when the refresh rate setting is changed?

But yeah, I am not completely dismissing ASW being the issue, just curious why that thing with the refresh rate setting does something with stopping the jitter despite refresh rate overall not actually changing? Maybe I should double check.

FWIW, for me, swapping between 90 and 120 doesn't really stop the wibbly jitter that much until a restart.

More to the point, if I slip an entirely blank layer in "underneath" Steam Link (since SpaceWarp will ONLY adjust the bottom-most layer) and make zero other changes to the renderer, suddenly the problem entirely vanishes (because it's warping a blank layer hidden behind the actual stream); that pretty much cements SpaceWarp as the cause, to me.

(This being the aforementioned band-aid solution.)

Ah, I see. IIRC, this doesn't happen on Windows with the same settings. Maybe this is something with the encoded frames being more complex to decode? It hitting ASW in the first place is worrying to me.

Regardless, I really appreciate the investigation work you have put in for this issue. Thanks!

Oh it absolutely should not be hitting ASW at all, no question. I would prefer a better solution than the band-aid, as well as an answer as to why this is now getting triggered where it wasn't prior to the recent Horizon OS update.

(FWIW, I can cause it on Windows as well, but it is harder to do so.)

@RealSupremium - If you try the public beta of the Steam Link app, this should be fixed.

Yep, the layer problem is fixed with the beta Steam Link client. However, the higher resolution still seems to cause issues. Seems like encoding is too slow? Not 100% sure how to read the graphs.

1344:

1280:

You're reading them correctly, and it's a thing on the list to look at. But at least this stops the 'wibbly' behavior when ASW erroneously kicked in, which was the more immediate priority.

Since the beta client has shipped, I'll close this out. However, I'm keeping the overall issue on my internal list (since I would like to stop the erroneous ASW triggering regardless).

And if further issues crop up, ping me on this issue.