The same thing happened to me but over on the windows side if you are able to duplicate the thread for that.
4060
I7 series
32GB DDR5
Since you wanted specs...
It worked fine before 2.3.5 ever since then it's been a mess.
Desktop 2 shows but 1 is blank on the dash board and won't return. I can still add a window and it shows correctly but I am unable to get the desktop 1 view back.
Hello @Flimsy-Fox,
Please test without steam-native - it is an Arch modification that is not supported. Use the normal steam package instead.
Please also consult https://github.com/ValveSoftware/SteamVR-for-Linux/blob/master/.github/ISSUE_TEMPLATE/bug_report.md for an updated list of the various logs and information that we need to get in order to be able to investigate.
Hello @Flimsy-Fox,
Please test without
steam-native- it is an Arch modification that is not supported. Use the normal steam package instead.Please also consult https://github.com/ValveSoftware/SteamVR-for-Linux/blob/master/.github/ISSUE_TEMPLATE/bug_report.md for an updated list of the various logs and information that we need to get in order to be able to investigate.
I have tested using steam-runtime, and the results remain unchanged. For completeness, I decided to also test on X11; the result is no different from on Wayland. After Steam was updated to 2.5, a "Please Wait" image would show on the Desktop view before returning to a blank screen.
Gist for Steam Runtime Diagnostics: https://gist.github.com/Flimsy-Fox/884480a730910583255b4fc33a18ed31
I noticed that decompressing the Steam Logs resulted in several files; how should I post them?
I noticed that decompressing the Steam Logs resulted in several files; how should I post them?
You can upload the .tar.gz here (for whatever reason github won't accept a .tgz though)
I noticed that decompressing the Steam Logs resulted in several files; how should I post them?
You can upload the
.tar.gzhere (for whatever reason github won't accept a.tgzthough)
Can confirm this issue on Fedora 41 Wayland using steam from rpmfusion.
I can confirm this on an Arch Linux setup with KDE Plasma, ALVR 21 and a Quest 2 with steam-runtime from the default repo.
I can also confirm this:
Arch x64 Gnome with ALVR And a Q3
Figured out a personal work around.
By running steam with the launch argument -pipewire , steam will then (at least on KDE Plasma, but it should work on other environments) pull a menu, requesting where to screenshare. Selecting the desired monitor will then do the trick. I found that it's buggy with two monitors but functioning correctly with only one enabled, though I will test more later.
If i remember correctly, pipewire is usually used for screenshare stuff. I don't really know the details of it.
I figured this out by running steam through terminal, and it mentioning to run with pipewire for screensharing. I hope this workaround is functional for all of you, and hopefully it will help for a solution to this issue.
After deciding to go back to x11 gnome, the issues have not left. the -pipewire arg does nothing for me
I can confirm the same issue, launching steam with "steam -pipewire" does show up the screenshare request menu, however the view is still completely blank in SteamVR
Wayland
after some struggle, launching steam runtime with the -pipewire option asks for screen to share just after the profile selection, inside SteamVR the selected display is shown correctly, but inputs does not work.
for wayland can anyone confirm the need of xdg-desktop-portal for it to work properly?
Wayland after some struggle, launching steam runtime with the -pipewire option asks for screen to share just after the profile selection, inside SteamVR the selected display is shown correctly, but inputs does not work.
for wayland can anyone confirm the need of xdg-desktop-portal for it to work properly?
I can confirm that this solution does work, as well as left-click inputs working through the xdg-desktop-portal. The desktop being blank after moving away and back into the view still remains.
I can confirm this as well.
on current plasma wayland, when using -pipewire fix, it just crashes steam entirely when attempting to launch desktop view now
on current plasma wayland, when using -pipewire fix, it just crashes steam entirely when attempting to launch desktop view now
I should've clarified in my temporary kinda fix comment that you also need to add -pipewire to your SteamVR launch arguments (i.e. %command% -pipwire). The issue where the Steam client still crashes after moving away from and returning to the Desktop View remains on my system (you have to remain in the view for a few seconds for the Steam client to crash).
It would be good to get Valve's comment on this, but I believe we're waiting on an upstream (CEF) fix to get a permanent solution to this (and a myriad of other issues relating to SteamVR on Wayland).
if it's a CEF fix we're waiting on, we may be waiting for a while; the OBS devs have been stuck against this wall for some time now: https://github.com/obsproject/obs-browser/issues/279.
this CEF issue mentions steam for linux in the thread; i imagine quite relevant here: https://github.com/chromiumembedded/cef/issues/2804
there appears to be an open PR for implementing wayland support into CEF here: https://chromium-review.googlesource.com/c/angle/angle/+/6164683
we can at least rest assured that there's some eyes on this issue; not just steam for linux users.
Ive developed a desktop overlay like valves one here if anyone really needs desktop in VR https://github.com/PhialsBasement/fnuidesktop-VR hopefully this can help valve skirt around this issue
Any update on resolving this issue? its happening on Fedora 43 KDE, but I get some weird wireframe line diagonally across it
we're unlikely to see progress here until CEF gets wayland support. you can track the PR here, where the PR owner claims "I am motivated to get this merged by end of January '26."
exciting!
we're unlikely to see progress here until CEF gets wayland support. you can track the PR here, where the PR owner claims "I am motivated to get this merged by end of January '26."
exciting!
I would temper expectations on this one as theyve been saying similiar stuff since the PR was open.
nowadays i feel https://github.com/wlx-team/wayvr is a much better option anyway.
Issue still exists in EndeavourOS x86_64 (Arch based.)
Issue still present in Bazzite (version 43) x86_64
I Confirm the same behavior in Kubuntu 24.04 wayland, steamVR beta version
Valve index, Radeon gpu
updates on wayland support in CEF! the original CR went stale months ago, but a new contributor has come along to pick up the work and continue on a new one. you can track it here. looks like they're looking to get it merged very soon!
updates on wayland support in CEF! the original CR went stale months ago, but a new contributor has come along to pick up the work and continue on a new one. you can track it here. looks like they're looking to get it merged very soon!
"Very soon" im not getting my hopes up again😭😭😭
EDIT ITS MERGED LFGGGG
Wayland support appears to be merged upstream: Wayland support (7844989) · Gerrit Code Review
Any news on what this means for desktop support in SteamVR?
i imagine it's just a matter of time. i'm not aware of any major blockers, and valve has been slowly improving wayland support (at least for steamOS desktop mode) for some time now.
I got the desktop to show with pointer. Input in xwayland windows works, but it seems to work best with hand tracking. Clicks don't seem to work with controllers. I'm not able to register input on wayland windows.
I'm running with these launch options and system settings
steam -pipewire
QT_QPA_PLATFORM=xcb steamvr -pipewire
7.1.5-1-cachyos
nvidia 610.43.03
steamclient beta 1785347151
steamvr beta 24308756
it would be awesome to have the desktop view working as it's a quite significant qol feature to have :)
%command% -pipwirex1 2025-07
Describe the bug
The Desktop View inside the Dashboard on Wayland is blank. Remaining in this view for a few seconds would cause the Steam client to crash and respring. Previously on X11, the Desktop View would be visible and usable for the first time, and then would revert back to current behavior (blank screen, crashing).
Switching to the SteamVR Beta branch has yielded no different results. Results have persisted since the release of 2.0.0.
To Reproduce
Steps to reproduce the behavior:
steam-nativeExpected behavior
Inside the SteamVR dashboard, each desktop is selectable. When a desktop is selected, the corresponding desktop is visible and interactable. Remaining inside each of the desktop views does not cause a Steam client crash nor for the VR dashboard to otherwise disappear.
System Information (please complete the following information):
Note: Commenters who are also experiencing this issue are encouraged to include the "System Information" section in their replies.