Valve released the latest update to SteamVR bringing with it a good few fixes, although most of it is for Steam Link. This follows on from a few recent Beta releases.
For Linux fans the changes are:
- Fixed issues with Room Setup launch.
- Experimental improvements to async support.
There's also OpenXR updates:
- Fix case where vive tracker bindings would all be bound to the first suggested binding.
- Add previously missing squeeze mapping for Vive trackers.
- Fixed menu binding mapping for Vive trackers.
- Remove trigger touch component from Vive tracker as it does not have one.
SteamVR:
- Fixed error spam when Vive tracker trigger pogo pin state changes.
SteamVR Home:
- Fixed looping 'updating' behavior when a content pack cannot be downloaded.
And then Steam Link for VR which is not yet supported on Linux:
To fully utilize the updates to Steam Link in this version of SteamVR, you must join the Steam Link Public Beta channel for the Meta app. To join, you must install Steam Link to your Meta headset, then you can opt into the Public Beta channel using this link https://www.meta.com/s/1hti7gedQ from your phone, or by using the Meta application on your phone to select the Public Beta channel in the settings for the Steam Link application.
- "Waiting for host" screen will now wait before displaying, meaning the app will transition straight to stream rather than the UI displaying.
- Small improvements to stream startup speed.
- Add additional errors to display if it's a video code error/video network error.
- Fix a few bugs around stream transitions to UI.
- Improve link establishment reliability in networks with occasional packet loss.
- Multiple fixes for crashes on the host PC.
- Reduced hitching from network problems with AMD cards.
Taken from the release post.
How's SteamVR on Linux for you now?
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
5 comments
I wonder what the chances are for an Index 2 to be revealed within the next year... 🤔
1 Likes, Who?
Did a good amount of testing for the beta of this one.
Had initial issues because my .steam directory was not what the setup script wanted and it couldn't find the runtime. After "fixing" that, it worked and I could enable async reprojection.
There a positives and negatives. Positive is that it works and that the new async implementation can make it extremely smooth. Unfortunately, it is also very erratic and I get periods of harsh fps drops. I do think that reprojection holds up during the fps drops so head rotation remains smooth, but other motion is so far down that it's very jarring. This contrasts with the 1.27.5 implementation where games that ran below 120 fps (my selected headset fps) were generally consistently running at lower fps. However, this lower fps was still higher than the fps drops of 2.6, so it didn't really affect me as much. It's also much more of a problem in games with a lot of quick movement.
All in all, I'll go back to 1.27.5. But it's good to see there is at least progress.
Had initial issues because my .steam directory was not what the setup script wanted and it couldn't find the runtime. After "fixing" that, it worked and I could enable async reprojection.
There a positives and negatives. Positive is that it works and that the new async implementation can make it extremely smooth. Unfortunately, it is also very erratic and I get periods of harsh fps drops. I do think that reprojection holds up during the fps drops so head rotation remains smooth, but other motion is so far down that it's very jarring. This contrasts with the 1.27.5 implementation where games that ran below 120 fps (my selected headset fps) were generally consistently running at lower fps. However, this lower fps was still higher than the fps drops of 2.6, so it didn't really affect me as much. It's also much more of a problem in games with a lot of quick movement.
All in all, I'll go back to 1.27.5. But it's good to see there is at least progress.
6 Likes, Who?
Quoting: EhvisHad initial issues because my .steam directory was not what the setup script wanted and it couldn't find the runtime. After "fixing" that, it worked and I could enable async reprojection.
Yep. Basically, run SteamVR using `bin/vrstartup.sh` instead of launching it through Steam. This might also work:
https://github.com/Scrumplex/Steam-Play-None
Last edited by artixbtw on 13 June 2024 at 5:14 pm UTC
0 Likes
Quoting: artixbtwQuoting: EhvisHad initial issues because my .steam directory was not what the setup script wanted and it couldn't find the runtime. After "fixing" that, it worked and I could enable async reprojection.
Yep. Basically, run SteamVR using `bin/vrstartup.sh` instead of launching it through Steam. This might also work:
https://github.com/Scrumplex/Steam-Play-None
I have SteamVR installed in nonstandar location. Steam wouldn't otherwise like it, but I keep it happy by providing it a symlink, so it thinks the installation is in original location. My Steam installation is in slow spinning media, but I like to keep Steam VR on NVME.
0 Likes
Quoting: artixbtwQuoting: EhvisHad initial issues because my .steam directory was not what the setup script wanted and it couldn't find the runtime. After "fixing" that, it worked and I could enable async reprojection.
Yep. Basically, run SteamVR using `bin/vrstartup.sh` instead of launching it through Steam. This might also work:
https://github.com/Scrumplex/Steam-Play-None
I use that to keep 1.27.5 out of the runtime. It's not needed for 2.6. My issue was that .steam/bin/steam-runtime didn't exist. Apparently .steam/bin should be a symlink, but it wasn't for me.
0 Likes
Patreon
PayPal
See more from me