On further testing I discovered that this seems to be related to async reprojection and have updated the issue title and body accordingly.

I am experiencing the same issue
Note: this problem occurs on both native & runtime versions of steam

Distribution: Arch
SteamVR version: beta 2.0.2
GPU: MSI GeForce RTX 3060 GAMING X 12G
Graphics Driver: nvidia-dkms-535.113.01-2

This is still an issue on SteamVR Beta 2.0.3

Still an issue on 2.0.5 too

Still an issue on 2.0.8, I reverted to last version of SteamVR 1 see https://github.com/ValveSoftware/SteamVR-for-Linux/issues/623#issuecomment-1780358506 for how.

Now that we got a forced "upgrade" to 2.0.8, I ran into this issues as well. (Ubuntu 23.04/Index/Nvidia 525)

Unfortunately no beta branch to downgrade, so now I have to do it manually.

Same issue on Fedora 38 here on SteamVR 2.0.8

With SteamVR 2.0.10 any error messages from before are gone and the new UI works too, except for wrong colours #570. Turning on enableLinuxVulkanAsync still results in a black display, so I am back to 1.27.5 for now. (VRChat really needs async.)

With SteamVR 2.0.10 any error messages from before are gone and the new UI works too, except for wrong colours #570. Turning on enableLinuxVulkanAsync still results in a black display, so I am back to 1.27.5 for now. (VRChat really needs async.)

Can confirm the same behaviour on my machine

This is still occurring in Steam VR beta 2.1.1.

Hi all!
For me this is no longer a problem in steamvr 2.1.2, hooray!!
2.1.2 launches properly with the enableLinuxVulkanAsync variable set to true in the vrsettings config

SteamVR is being temperamental at the moment and won't recognize the headset display so I can't test and confirm, but I'll fiddle with it some more over the weekend when I have more time.

I had that problem a few days ago - all I had to do was unplug the DP cable while the computer was off, turn it back on, and plug it back in before starting steamvr and it's been fine since!

@DaeTheDragon Thanks a lot, that did the trick! It seems like this issue crops up for me every few weeks or so so it's really great to have a workaround now.

Unfortunately, Valve has now pushed 2.1.3 which is causing me to run up against #639 so I still can't re-test this bug. Just a big ol' game of whack-a-mole with these betas, lol.

This is unfortunately still occurring for me with beta version 2.1.5.

This is still occurring with version 2.1.7.

@DaeTheDragon Thanks a lot, that did the trick! It seems like this issue crops up for me every few weeks or so so it's really great to have a workaround now.

Unfortunately, Valve has now pushed 2.1.3 which is causing me to run up against #639 so I still can't re-test this bug. Just a big ol' game of whack-a-mole with these betas, lol.

This is unfortunately still occurring for me with beta version 2.1.5.

This is still occurring with version 2.1.7.

heya!! sorry I haven't replied here to your response, been pretty hectic!
anyway- actually for me, it has been working fine from version 2.1.2 up to version 2.1.7!
I've been able to turn on VulkanAsync in the settings file and have been using it without any problems since I made my last post here, strangely enough!!
how odd that you were still unable to!

anyway, since hotfix update 2.1.8, the issue you're experiencing has returned for me, black void again, and the only fix is to turn VulkanAsync back off again...

I'm probably going to drop back to 2.1.7 where my VulkanAsync was still working, until a newer update works for me!

Hey I'm also experincing this on 2.1.10 Beta

Distribution: EndeavourOS
SteamVR version: beta 2.1.10
GPU: MSI GeForce RTX 3060 12G
Graphics Driver: nvidia-dkms 545.29.06-1

But what I find interesting or maybe helpful, is if that is async reprojection based on Vulkan, I was learning it once, but then got booted off to another project, there are validation layers that could be turned on, and maybe they can pinpoint us to a root cause?

I'll try to find if that is possible, and leave this comment as is, as maybe some Vulkan expert can quickly say that it is/isn't possible.

EDIT: Found out you can very easliy download vkconfig fire it up (on EndeavourOS it was a vulkan-extra-tools package), and the rest takes care of itself, you just need to change the log filename to a absolute path and Vulkan pipes all the errors by itself, I know that SteamVR is build upon OpenVR, but can anyone say if the asyncreprojection is opensourced? If it is, I may poke and try to fix it just for pure experience.

I'm also attaching the file that was outputted.
vrstartup.txt

This is still occurring as of SteamVR 2.2.1.

Behaviour is still the same in SteamVR Beta 2.2.3

Hello, still happening with SteamVR Beta 2.2.4

AMD RX 6600 XT user.

Seemingly the best way to fix this for now is using temp_v1.27.5 beta and making sure nodcc is ~not~ set within RADV_DEBUG options. This will cause ~major~ noticeable graphical corruption of SteamVR overlays at the benefit of flawless reprojection in-game, at least from my testing.

I used to use v1.14 all the time and it is still the most stable version in regards to reprojection, rendering and just about everything else, but that one requires changing selected Proton version of many games to 5.13.

@Hisanatos

can anyone say if the asyncreprojection is opensourced? If it is, I may poke and try to fix it just for pure experience.

I'm not sure, but I wish you luck! 💜

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/616#issuecomment-1841243338

SteamVR is, in fact, fully closed source. This GitHub repo exists exclusively for reporting issues. There are open-source alternatives to SteamVR for Linux, see (https://gitlab.com/gabmus/envision). Though they're not quite as plug-and-play as SteamVR... well as SteamVR is supposed to be.

I've tested it on 1.27.5 and it works flawlessly on Nvidia hardware, I can even do some Expert+ Camilia songs in the Beat Saber, though I've noticed that it can "lose" the controllers, and even though I sliced through some boxes it doesn't register, will try to drill into why it happenes.

Beta 2.3.1 is still broken though, SteamVR startsup and Valve Index only show black (well more like grey) image. VR view shows that the headset is correctly tracked.

As there is a difference between 1.27.5 and 2.X.X maybe there is some information that would help Valve fix it? (Of course question to Valve :) )

Having the same issue here as well with 2.3.3. Hoping they fix it soon because currently if I revert to 1.27.5 and try to run any VR title it simply crashes Steam and SteamVR.

Without async re-projection most games have a ghosting effect making them unplayable.

Hopefully this gets fixed soon.

This is still occurring with version 2.4.1.

This seems to be fixed, with SteamVR Beta 2.5.1!

This seems to be fixed, with SteamVR Beta 2.5.1!

While I assumed the update announcement meant the issue was fixed, I am still observing the same happening on my end. Nothing is being displayed inside the headset on that beta.

RX 6600 XT, Mesa driver, Valve Index, recently updated Artix Linux, Steam client stable branch

Yup. I have to take back my comment up there. I thought I had enabled enableLinuxVulkanAsync again, but I forgot to save before testing :O

Still broken with Beta 2.5.1

Today Steam updated for me and it seems that I lost async even with the temp_v1.27.5 branch of SteamVR, which has been working well for me for over half a year. Not sure if it is bad luck or if Steam and/or runtime changes are no longer compatible with the old SteamVR.

Specifically I got the warning about getcap not being in path despite the fact that I run all of Steam with PATH="$PATH:/usr/sbin:/sbin". So something is resetting the environment in a way that earlier Steam did not. Even though vrcompositor-launcher still has the capability set async is not turned on, as if the environment inhibits this in some way.

I also note my external overlay (WlxOverlay) no longer working (starting?) with this new setup, possibly the sandbox inhibits this as well.

Update: Running SteamVR manually, outside of Steam, makes both async and the overlay work again.

~/.steam/debian-installation/steamapps/common/SteamVR/bin$ ./vrstartup.sh

I hope async is fixed with SteamVR 2 soon.

@vermeeren You can try running SteamVR with Steam-Play-None to bypass the sandboxing that Steam does:
https://github.com/Scrumplex/Steam-Play-None

@vermeeren You can try running SteamVR with Steam-Play-None [..]

Please don't do this. Or if you do, please do not report any issues you run into when you do this to us.

We are aware of the async repro issue. Currently being investigated.

Please don't do this. Or if you do, please do not report any issues you run into when you do this to us.

@TTimo I am aware running it outside of Steam's environment is a big hack and will only do this for the temp_v1.27.5 branch. Indeed the old version has various issues but once actually in-game it does work well with perfect async repro.

VRChat very often is in the 30-50fps range, without async there is some very odd double vision blur-like implementation of repro, also when I tested early SteamVR 2 versions. Possibly #633 #613 not sure.

We are aware of the async repro issue. Currently being investigated.

Good to hear, I'll be glad to test any new versions that may fix this, without any env hacks, when possible!

Hello,

SteamVR beta 2.6.2 addresses an issue observed when async support is enabled. Please retest. Make sure to include an updated set of logs with your new observations (see https://github.com/ValveSoftware/SteamVR-for-Linux/blob/master/.github/ISSUE_TEMPLATE/bug_report.md for details).

Hey, works for me

Update: Running SteamVR manually, outside of Steam, makes both async and the overlay work again.

~/.steam/debian-installation/steamapps/common/SteamVR/bin$ ./vrstartup.sh

I hope async is fixed with SteamVR 2 soon.

I get an error message "vrstartup.sh[20259]: ERROR: no steam runtime environment set, please use sniper SLR"

Also, not sure if it's been the case for a while, but I remember adding " "enableLinuxVulkanAsync" : false " under the steamvr section used to work to make SteamVR games run smooth again. Now, it just deletes the line automatically.

Works for me! Sure glad I didn't know what I was missing... quite an improvement!

The file to edit is ~/.steam/debian-installation/config/steamvr.vrsettings

...
   "steamvr" : {
      "enableLinuxVulkanAsync" : true,
...

and using Beta versions of both Steam and SteamVR:
Steam menu: Steam->Settings->Interface->Client Beta Participation->Steam Beta Update
Steam menu: View->Library ( or Hidden Games ),
SteamVR app, Gear Icon (Manage) to far right of Launch button->Properties
Betas->Beta Participation-> beta SteamVR Beta update

Just dropping it here for anyone else having similar issues; I didnt get Async to activate (error in logs trying to activate async) and it seems I at some point had manually setcap on vrcompositor.

And it seems (so unconfirmed really) that since I did set it manually/wrongly/but-not-wrong-enough the steamVR scripts thought it was okay but fails to actually get the capability. I removed the cap with setcap -r and let the script trigger the prompt for password to set the cap and after that it worked.
Maybe some interaction with pressure-vessel that gets confused due to how it was set or something.. or the check if it is set doesnt actually validate that it is correctly set?

Works for me! Sure glad I didn't know what I was missing... quite an improvement!

The file to edit is ~/.steam/debian-installation/config/steamvr.vrsettings

...
   "steamvr" : {
      "enableLinuxVulkanAsync" : true,
...

and using Beta versions of both Steam and SteamVR: Steam menu: Steam->Settings->Interface->Client Beta Participation->Steam Beta Update Steam menu: View->Library ( or Hidden Games ), SteamVR app, Gear Icon (Manage) to far right of Launch button->Properties Betas->Beta Participation-> beta SteamVR Beta update

Yep, the smoothest experience is now is ""enableLinuxVulkanAsync" : true," not false, like a few years ago. It's still not perfect, or as good as it used to be back then, though. Amid Evil VR is barely playable, though VR Chat seems ok, in the hub at least.

Not sure if using the beta version of Steam makes a difference, though.

Beta 2.6.2 works for me, without any environment hacks like Steam-Play-None. The async implementation seems different compared to 1.27.5 which is interesting. Very happy to see it working!

Issue still present on Nvidia GPUs, even on the new 2.6.2 beta, feels particularly horrible in heavy worlds/worlds with a lot of heavy avatars in VRChat (altho it is also present in other graphically heavy games/bad performant games), it get a bit better if i got into video settings and lower my resolution all the way to 20%, but again only when there are not many avatars and the world is not heavy.

If there are many avatars or the world is heavy double frames and shakiness comes back if i try to move my head in the headset, and its worse when i move left and right than when i move up and down.

Altho i noticed something weird, when there is only one moderately heavy avatar, and the ghosting/double frame is not too bad, it actually gets better overtime, after about 30 minutes its practically gone, which leads me to this question for Valve (not really sure who to tag for that, @kisak-valve can you help out with that?): is there some filter thats dependent on frame rate of the application for the pose data of the headset before its used to actually reproject the frame? Because if there is, it really feels like its not tuned correctly :/

I'll try to attach a video of what i see in the headset later

Gotcha, i'll open a separate issue with the video from the headset later then.

I think my crashing when enabling async reprojection was fixed with this as well. It is so smooth as well.

(RX 5700xt, Arch, Hyprland, Index)

Closing per the last few comments. Thanks all.