protonscr

Abandoned Repo?

steamvrclosed
ValveSoftware/SteamVR-for-Linux#792 · opened 2025-06-25 by peq42 · updated 2025-07-21 · 4 comments · github
Ppeq42 2025-06-25 github

Judging by how slow updates to steamVR have been, even more for Linux, and the massive amount of issues users face and report that goes unnoticed or ignored(some issues here are years old, got many comments but haven't been solved at all) was this Repo abandoned by Valve?

Can we ever expect SteamVR to work as well on Linux as it does on Windows? Are we going to be at Microsoft's mercy for VR(all millions of us)? Is steam link on quest EVER going to work with steamVR on Linux as has been asked for 2 years now?
https://steamcommunity.com/app/250820/discussions/5/4036977035343108208

SSpacefish 2025-07-09 github

I think that´s a misperception. SteamVR Linux updates are released quite frequent since ~1.5 years and bugs get fixed.

There is pretty good evidence, that Valve is working on a Standalone Linux based VR Headset, so i guess they already have a lot of stuff in place on their internal builds which they don´t want to release yet. Working on two versions in parallel makes it almost impossible to merge them later on, or you have to constantly rebase one version onto the other, so i guess they hold off a littlebit with big fixes in the "public" version.

Ppeq42 2025-07-10 github

well then why don't he have steamlink working with linux (VR) games? Why are majority in the community tab complaining about how buggy it is? Why are the changelogs on the steam page itself showing few to no fixes every other month?

CCarbonNotes 2025-07-15 github

Can we ever expect SteamVR to work as well on Linux as it does on Windows?

I suspect many of the issues with SteamVR on Linux actually come down to lack of certain advanced features in underlying ecosystem components. Features that Valve has been systematically helping to implement...

In 2018, there was no way to steal a display from the X server, and Valve was a large part of the effort to make that happen. Nobody needed this capability until VR came around, so it didn't really exist.

After that, there were missing features in radv necessary to make async reprojection work at all. Valve was a large part of the effort to make that happen. Nobody really needed those features until SteamVR came knocking.

Once Async Reprojection started working, there were scheduling issues causing it to behave improperly. There have been multiple attempts to improve AMD GPU scheduling, including moving from round-robin to a FIFO queue, adding multiple FIFO queues, and most recently Igalia's Fair(er) GPU scheduler: https://blogs.igalia.com/tursulin/fair-er-drm-gpu-scheduler/ . This was an issue, but nobody was all that bothered by it until you bump into something like SteamVR, which is a heavily multi-process often GPU-bound application. That made it necessary to have significantly better GPU scheduling to ensure consistent low-latency execution.

While Igalia doesn't specifically call out the work being in partnership with Valve, the fact that they test it on a Steam Deck makes me suspect that Valve was involved. Seems like you'd test it against a standard desktop card or mobile APU unless someone had paid you to help improve their current or future products. (Of course, every AMD GPU Linux user benefits from the work!)

Inbetween these improvements and contributions, Valve has been making games (HL: Alyx, Deadlock, CS2, etc), new hardware (Steam Deck), adding other new features to the Linux graphics stack (HDR -> Steam Deck OLED), and generally investing heavily in bringing the Linux gaming ecosystem up to par with the latest and greatest on Windows. (Lots of time and money into DXVK and Proton! SteamVR on Linux is worthless if VR games run poorly...)

It takes time to get new Vulkan extensions through Khronos and merged into the spec: https://registry.khronos.org/vulkan/specs/latest/man/html/VK_VALVE_fragment_density_map_layered.html

It takes time to coordinate new features like HDR through the whole stack (GPU driver support, design a vendor-neutral kernel ABI, integrate support into Mesa, desktop environments add support, X11 / Wayland add appropriate protocol extensions, so on and so forth.)

It's not that Valve isn't working on it, it's that they're trying to do things right, participating in open source and building infrastructure that everyone benefits from. Some companies are content to just grab the OSS code, hack something together, and ship a half-assed product that only works with their custom, device-specific version of everything. It'd be done fast! But honestly it'd suck if we had to run a special Valve-patched version of the kernel, graphics stack, and desktop environments just to get SteamVR to function... Even then, you'd probably end up with limited hardware support, and eventually components would start to fall behind... It'd be done fast, but not well. Since Valve is contributing to upstream development, it slows things down, but ensures that everyone benefits. Valve HMDs work, but so do HMDs from other vendors. Other projects can benefit from the work Valve is funding, such as Monado. A rising tide lifts all boats.

Quoth words of a wise man, "These things, they take time."

SSpacefish 2025-07-18 github

Why are the changelogs on the steam page itself showing few to no fixes every other month?

They constantly do fix things! See https://github.com/ValveSoftware/SteamVR-for-Linux/issues/794 for an example, it took like 7 days to get fixed. That´s pretty fast compared to most other software made by bigger companies out there.

Nothing extracted yet.