I am affected as well. Steam Remote play doesn't work, neither does remote play together. Input and audio works perfectly.

The computers used for testing were:

• Archlinux desktop (AMD R9 Fury, Mesa, RADV), native steam (and flatpak)
• Archlinux laptop (Intel integrated graphics), via flatpak

Clients tested:

• Android application, LAN/LTE
• laptop with sway (with and without hardware decoding)
• desktop with sway (with and without hardware decoding)

Servers tested:

• :x: desktop with sway (with flatpak, without, with and without HW encoding)
• :x: laptop with sway (with and without HW encoding)
• :x: desktop with plasma wayland (with HW encoding)
• :heavy_check_mark: desktop with i3 (with HW encoding)
• :heavy_check_mark: desktop with plasma on X11 (with HW encoding)

I am thus reasonably certain that the issue is with Wayland or XWayland (I would need to test plasma without HW encoding to be sure there are not two separate symptoms here). Screen sharing from applications like Firefox do not work on Wayland either.
A possible future solution might leverage pipewire for capture.

I haven't seen anything on the client besides corruption (like uninitialized memory, with a few textures from former apps), even after a game starts. I used simple games for my tests (FTL: Faster than light, Crypt of the necrodancer), and only tried 3D games like Portal 2 on X11 to confirm it still worked. Do 3D games use a different capture method? (Vulkan layer, OpenGL lib injection). Which ones should I try?

Same issue on Plasma Wayland (tested on Arch Linux). I assume Steam would have to ask pipewire to stream the desktop.

Same issue on Sway

Same on Fedora 32, with RPMFusion steam, and Sway.
Audio works. But no visual on the steam link device iPhone current iOS.

Same issue on Fedora 32 + Gnome wayland

anyone tried the flatpak version?

same issue on Arch Linux swaywm/wayland + iPad setup

anyone tried the flatpak version?

@PMaynard: Re-read my comment, I am using the flatpak version.

This is pretty much a known issue for every wayland environment at that point, so I don't think there's much point in adding pages of comments that everyone has the same issue, and it would be more productive for everyone to upvote the issue.

Valve seems to be working on a wayland compositor, I believe the capture functionality could be integrated into it, and then have the compositor act as a client to also display stuff on the screen (if needed). Not sure if that's the way they want to go forward with, but that's what I would do. Pipewire and waypipe are other, more general options.

Playing around with this a bit more - in a sway session at least it seems that only the big picture interface has trouble being streamed. Starting a game while looking at the normal monitor with the keyboard launches the game, and the game will then appear over the steam link (android app or standalone device) properly. This is only a partial work around, but it does mean xwayland has what it needs to capture and stream the game.

@yokem55, that's interesting, it never worked for me. Neither steam nor browsers are able to capture other Xwayland windows, only displaying a black background. @emersion hinted that it should work already, so I am not sure what's going on, I will re-test soon. Some of it could be due to multi-monitor specificities.

@emersion hinted that it should work already, so I am not sure what's going on

I think there has been a missunderstanding as @emersion was talking about Steam Play, which works fine on wayland, whereas this topic is about Steam Remote Play, which doesn't.

@emersion hinted that it should work already, so I am not sure what's going on

I think there has been a missunderstanding as @emersion was talking about Steam Play, which works fine on wayland, whereas this topic is about Steam Remote Play, which doesn't.

I think you misunderstood. For me as well, steam link/remote play works on wayland for a game but the big picture mode window is just black with a few artifacts.

That's exactly what I'm seeing. So streaming demonstrably works. Just unusable if you can't select a game.

I don't want to create additional noise, but to document what I think we're all talking about.

1 My Steam Link Android Phone screen before connecting

2 Pressing Play on the phone, trying to stream big picture mode

3 Quick-Selecting dicey dungeons below, skipping big picture streaming

And as OP posted, even for the arrifacted big picture streaming, commands from the phone get relayed just fine. You just can't see it.

@maweki True, I should have been more specific. The Problem is not streaming the games on Wayland via Steam Remote Play, but anything desktop related.
It still holds true, that @emersion was talking about Steam Play, which has nothing to do with Steam Remote Play.
Furthermore, at least for me it is not the Big Picture mode itself which is the problem. You can go ahead and in the Steam Link settings choose "Launch Mode: Desktop". This won't bring up the Big Picture Mode but still won't stream anything useful until you start a game.

I finally found a workaround!
The problem seems to be the wayland compatibility of steam. This seems counter-intuitive at first, but seemingly all screen capture software has trouble with wayland (just do a quick search for wayland screen capture black screen on the net)
So steam has to run under x11 to support remote play. Luckily we have a way of using x11 applications under wayland with Xwayland. Now we "just" have to force steam to run under Xwayland

First we start a Xwayland server with a seperate display Xwayland :11. The display number should be any display number which is currently unused. Then start steam with DISPLAY=:11 steam.
Done.

You can fiddle with the Xwayland settings until you are satisfied
Now just to make it a little bit more comfortable...

I finally found a workaround!
First we start a Xwayland server with a seperate display Xwayland :11. The display number should be any display number which is currently unused. Then start steam with DISPLAY=:11 steam.
Done.

So what you're basically saying is, while Steam or Linux (who is responsible for that?) seems to run most games in XWayland already, the steam client proper does not and is therefore not capturable? This would imply that games that work with and use wayland would not be streamable either, yeah?

So what you're basically saying is, while Steam or Linux (who is responsible for that?) seems to run most games in XWayland already, the steam client proper does not and is therefore not capturable? This would imply that games that work with and use wayland would not be streamable either, yeah?

That's correct. In fact that's how I stumbled upon this "solution". I tried adding non-steam applications to see which could be captured and which not. And even some steam games couldn't be captured (Wasteland 2 for example).
By default all applications should start under wayland and only legacy applications shouldn't.
By running steam inside the Xwayland server, steam will start all other applications in this instance as well. So all games should be streamable from there on.

Edit:
One more observation. Starting Xwayland with the -rootless argument (which would be desirable) won't work. Which leads me to believe that maybe it's not that steam isn't running in a Xwayland session, but rather the default Xwayland implementations in Gnome/Sway/"you name it" all use the rootless Xwayland path. While this is definitly the right choice I wonder if there is a way around this.

Edit2:
For gnome I can confirm that Xwayland runs as rootless which causes the issue with remote play.
So one fix could be to disable Xwayland for Gnome alltogether by adding --no-x11 to the gnome-shell command in the systemd service file, and autostarting a Xwayland server with a custom command and without -rootless.

Also for all wlroots based wayland compositors (sway, cage, gamescope, ... ) this is a bigger Problem as it is hardcoded in https://github.com/swaywm/wlroots/blob/6c08fe979615ac88648eb91c87ea4c41fa1d7bdf/xwayland/server.c#L65.
Though there has been a merged pull request in october which could help here.
If we create a new file with the content:

#!/bin/bash
Xwayland ${@##-rootless}

make it executable and pass it to the compositor via WLR_XWAYLAND=... the Xwayland server should be started without the rootless argument. Given the used compositor uses the required version of wlroots (>0.12.0)

Any progress on this? Wayland is finding its way into more and more systems with Fedora, Ubuntu and others enabling it by default. Some players (me included) switch to wayland for gamer-oriented features such as a better multi-munitor support, better high refresh rate support natively and native HiDPI options, as of now I cannot stream any game to my Steam Link nor to any of my friends through Remote Play Together without switching first to X11 (which is really not an option in my case). Now that multiple Wayland streaming alternatives exists (most browsers support screen sharing on wayland, OBS works fine too) I hope Valve can do something about it before too many of us are stuck without a very cool and useful feature

So here's what I think is happening, plus 2/3 of a workaround (maybe someone else can figure out the rest of this):

Most games run in an Xwayland window, and Remote Play is able to stream the contents of that window just fine. Anything that's running in a native Wayland window doesn't work (DOOM Eternal, for example), because Remote Play isn't using any capture methods that work on Wayland.

Even though Steam itself runs in Xwayland (it's definitely not Wayland native), it doesn't try and stream the contents of that window. Instead it tries to capture the entire desktop, which won't work if you're using Wayland. It's probably a sensible choice since a lot of games will try and show little launchers or popups or whatever and you'd want to be able to click on them or do whatever you need to do to get the game to launch. But regardless; it breaks streaming for Steam itself.

If you do something like this: Xephyr :1 -screen 1920x1080 & DISPLAY=:1 steam it will put steam into it's own little X11 box, and when it streams the "desktop" it's really just streaming the contents of that X instance. The problem is that games try to launch inside of that X instance, and at least the games that I tried didn't work (missing Vulkan libs or somesuch). But you can make games launch outside of Steam's little sandox by setting the launch options to DISPLAY=:0 -- %command%.

However... Remote Play doesn't switch to streaming the contents of that Xwayland window. It just sits there streaming the Big Picture interface. So if there's a way to convince Steam to stream that window I think we'd be in business.

Obviously the real solution would be for Steam to be able to capture the desktop on Wayland, probably with xdg-desktop-portal. OBS did this recently. There's a plugin here that was merged into OBS proper. So it's definitely doable now.

Is this being actively worked on by Valve?

Is this being actively worked on by Valve?

I imagine it must. At least the odd guy. The plan for SteamOS and the new hardware can not be to stay on X for the rest of eternity. It would be unusual for Valve to drop the ball on this long-term architecture stuff.

Has anyone come up with any other solutions for this problem? Neither the Xephyr not Xwayland solutions listed above have worked for me.

Gamescope now has a PipeWire stream, which was just implemented less than a month ago. The issue is linked above.

@kode54 What exactly do you mean? What issue is linked above? And what exactly does Gamescope have to do with in-home streaming not working properly under Wayland?

@Mushoz If I understand correctly, PipeWire allows for screen capture under Wayland, which seems to be the capability missing currently. PipeWire is an independent library Steam could also use to remedy the problem of screen capture under wayland.

Issue: https://github.com/Plagman/gamescope/issues/130#issuecomment-727611236
PR: https://github.com/Plagman/gamescope/pull/219

The latest Steam client beta added PipeWire support:

Enabled pipewire desktop capture by default on Linux, pass -nopipewire on the command line to disable it

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2872724078255992088

I gave it a quick try on Fedora 34 (Gnome 40, Wayland, Intel UHD + Nvidia 470.63.01):

• Steam requests desktop capture as soon as it launches (e.g. In Gnome, the "Share Screen" modal/portal is shown, asking for confirmation.)
  • Note: I think an improvement could be to request this when streaming is about to start instead of when the client launches.
• I'm able to stream games as long as I disable the Steam in-game overlay.
  • Streaming seems to freeze as soon as the overlay notifications are shown.
  • While frozen, streaming does resume as soon as the game is closed.
  • Disabling the overlay seems to resolve the issue.
  • Games tried: Shadow of the Tomb Raider, Parkitect (both in 3840x2160)
• Streaming my entire desktop does seem to work well.
• Using Big Picture mode while streaming crashes after a couple of minutes.
  • Crash: src/steamUI/gamestream/desktopstreamthread.cpp (151) : Driver deadlock in hardware accelerated desktop capture, aborting
  • I worked around this by exiting Big Picture as soon as I start streaming.

  * Streaming seems to freeze as soon as the overlay notifications are shown.

That's not a streaming issue, it's steam client itself being half-borked under wayland. Notifications freeze and stutter, chat becomes unresponsive whenever there's an animation or multiple steam windows open (i.e. friends + library + chat)

It's been like this for a long time, and the only way to get a fluid steam experience (that also breaks launching most games) is passing env SDL_VIDEODRIVER=wayland steam

https://github.com/ValveSoftware/steam-for-linux/issues/4924
https://github.com/ValveSoftware/steam-for-linux/issues/7245
https://github.com/ValveSoftware/steam-for-linux/issues/8020
https://github.com/ValveSoftware/steam-for-linux/issues/6500
etc..

The latest Steam client beta added PipeWire support:

Enabled pipewire desktop capture by default on Linux, pass -nopipewire on the command line to disable it

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2872724078255992088

I gave it a quick try on Fedora 34 (Gnome 40, Wayland, Intel UHD + Nvidia 470.63.01):

* Steam requests desktop capture as soon as it launches (e.g. In Gnome, the "Share Screen" modal/portal is shown, asking for confirmation.)
  
  * Note: I think an improvement could be to request this when streaming is about to start instead of when the client launches.

This is tracked in https://github.com/ValveSoftware/steam-for-linux/issues/8098

[...]
* Streaming my entire desktop does seem to work well.

For me streaming Steam doesn't work, I just get a black screen -- I'm using Flatpak'ed steam though. I've added permissions to access pipewire though:

$ flatpak --user override --filesystem=xdg-run/pipewire-0 com.valvesoftware.Steam

If I change to a non-steam window, this works however. Switching back to big picture suddenly makes things work. Weird.

Yep, recording its own window fails:

Changing record window: 0x1a0002c
SynchronizeClientState(): setting activity to k_EStreamActivityIdle: Steam Controller Configs - Big Picture
Bitrate adapter: state = 2, minRTT = 1, maxRTT = 102, gain = 0.75, bitrate = 2500
SynchronizeClientState(): setting cursor hidden
OnFocusWindowChanged to window type: k_nGameIDControllerConfigs_BigPicture, AppID 413090
Loaded Config for Local Selection Path for App ID 413090, Controller 4: /home/leonard/.local/share/Steam/steamapps/workshop/content/241100/1873878621/1322320470301167556_legacy.bin
CLIENT: Got control packet k_EStreamControlSetActivity
CLIENT: Got control packet k_EStreamControlHideCursor

W/o big picture, everything works.

UPDATE: After starting a game outside of BP, closing it, and starting BP again, even that works. I need to fiddle around some more.

Using Big Picture mode while streaming crashes after a couple of minutes.

* Crash: `src/steamUI/gamestream/desktopstreamthread.cpp (151) : Driver deadlock in hardware accelerated desktop capture, aborting`

* I worked around this by exiting Big Picture as soon as I start streaming.

I got exactly the same issue using Gnome/ Wayland. To be more specific it only crashes when i start a game using Steam Big Picture.
I uploaded my error log here: https://pastebin.com/UrBCxAGs
The interesting part should be at the end.

While desktop streaming seems to work okay, starting a game directly from Stream (no Big Picture) does not really work for me.
I only get a black screen on my Steam Link App.
-> Shadow of the Tomb Raider is interesting tho: The launcher works and gets transmitted to my phone, but the game itself doesn't work and Steam actually crashed

Streaming the desktop shows not the whole desktop, but that could result from me using fractional scaling.

Other than big picture crashing. I can't get streaming to fully load on any device. all devices get audio. you can see the cursor on steam client machine but the cursor doesn't move. it seems to be the cursor of the remote system. You don't get any video on mobile (launching the game first to avoid crashing).

This is on a wlr based compositor but from the comment above it seems to be effecting gnome based ones too.

Has anyone managed to get this semi working on wayland and got any tips?

I've gotten this working (with pipewire) with some caveats, and only outside of flatpak because the -pipewire flag does not seem to work there.

1. There are big issues with HiDPI and scaling. Consider the following situation: output DP-1 is 4k with a scaling of 2. When I try to stream with remote play steam uses pipewire to grab the display (which steam takes the entirety of in fullscreen mode), but then crops it to the size of its window, which it believes to be 1080p. Then only the upper-right 1/4 of the display is actually streamed.
2. When streaming is correctly grabbing the entire display (either in 4k with scaling=1 or 1k with scaling=1) then there appears to be an encoding issue which messes up how the stream is shown (picture attached). Note that this does not happen in other pipewire video stream consumers such as chromium or firefox so it must happen on the steam or TV side.

how it's supposed to look:

how it looks:

I'm running into segfault crashes that seem to be related to my (somewhat exotic) display configuration. I've tested various scenarios with both a physical Steam Link and the Steam Link app below. I have a primary 1440p@170 that I'm trying to stream from, and a secondary 1080p@60 monitor. The primary monitor is to the right of the secondary and positioned such that the top edge is below that of the secondary monitor, such that (0, 0) in the workspace is somewhere above the secondary monitor and not on a physical screen.

Relevant information:
Distribution: Manjaro
DE: Plasma 5.23.1
PipeWire version: 0.3.39
Streaming client: OnePlus 6T (display resolution of 1080x2340)

All tests were conducted with hardware acceleration disabled on the host.

Layout: Original
Primary resolution: 1440p@170
Result: Immediate crash iff PipeWire is granted permission before streaming begins. Otherwise, first quarter of client screen horizontally displays last quarter of host screen (screen is basically wrapped around) and crash after indeterminate amount of time.

Layout: Original
Primary resolution: 1080p@170
Result (physical): Crash after indeterminate amount of time (sometimes almost immediately) - I was able to launch a game successfully, but upon quitting the client locked up and then segfaulted after tabbing out.
Result (app): Crash after a few seconds.

Layout: Primary lowered such that (0, 0) is on secondary monitor
Primary resolution: 1440p@170
Result (physical): Immediate crash iff PipeWire is granted permission before streaming begins. Otherwise, crash after attempting to launch game.
Result (app): Crash after a few seconds. In this case I also observed a crash a few seconds after the remote client disconnected.

Layout: Primary lowered such that (0, 0) is on secondary monitor
Primary resolution: 1080p@170
Result: Immediate crash iff PipeWire is granted permission before streaming begins. Otherwise, crash after an indeterminate amount of time.

Layout: Primary moved to left such that (0, 0) is on primary monitor
Primary resolution: 1440@170
Result: Mostly works - screen goes black after game exits, but this is probably an unrelated issue.

Layout: Primary moved to left such that (0, 0) is on primary monitor
Primary resolution: 1080@170
Result: Mostly works - same issue with the screen going black.

From this, it seems that a crash is guaranteed if the origin of the workspace does not correspond to the top-left corner of the primary (streamed) monitor. I don't think the origin not being on a physical screen has any bearing in this case. However, it does seem to cause the described "wrap-around" bug in the first scenario, but only if the primary display is 1440p (or I imagine anything larger than the client can display without scaling).

Also of note is that I can reproduce the crashy behavior as well as the screen wrap-around effect on GNOME 40 as well, although it seems to always exhibit the crashy behavior seen on Plasma when casting permissions are granted after streaming begins, regardless of when permissions are granted. However, I did not test this extensively.

Managed to make it work with Flatpak version on Fedora 34:

1. Install Flatseal and add xdg-run/pipewire-0 to other files in filesystem category
   
2. Run steam from command line with:

flatpak run com.valvesoftware.Steam -pipewire

1. Everything works:
   
   Second step is only necessary until it will become default option as in Steam Beta.
   Probably when it becomes default there will be update to flatpak manifest and first step will not be necessary as well.

@eaglesemanation Does it require picking the capture device on startup, like it does for me when I enable Pipewire mode? This may depend on having two or more displays attached.

@kode54 Yes, it does. And this behaviour is documented in xdg-desktop-portal documentation under Start() method. I don't know of any way to avoid that behaviour, even though it would be reasonable to bypass this dialog in case desktop has only 1 screen connected.

Edit: Currently this feature is being discussed in https://github.com/flatpak/xdg-desktop-portal/issues/649

I don't think it's possible to bypass such dialogs, as they're invoked by the xdg-desktop-portal implementation when something opens them for capture.

The new beta client fixes the crashing bug, many thanks!

However, it appears to worsen the bug affecting monitors not situated at the top-left of the workspace on both axes. If my primary monitor is set to 1080p and configured to the right, the client streams only the last column of pixels stretched across the screen (with the -pipewire-dmabuf option - otherwise it's blacked out). 1440p causes slightly different behavior with a bit more of the right side of the screen being visible.

I also tested specifically with a vertical offset - if I configure my primary display to the left but offset vertically from the secondary, the area captured and streamed is offset by the same amount - so if in terms of workspace coordinates my display is situated at (0, 500), the workspace area captured starts at (0, 1000) so that the top 500 rows of the display are cut off and the bottom 500 are black (or repeats of the last row when using DMABUF).

Trying this with sway... It works with games but not with Big Picture / Desktop.

1. Streaming starts but the video freezes at the initial Big Picture screen. I can hear the audio, and the host system reacts to client's controller input, but nothing more.
2. Curiously, if I start a game from the host, the game starts streaming just fine, and I can even open the in-game Big Picture overlay and use it normally. Launchers however do not get streamed, only actual games.
3. After I close the game (coming back to Big Picture) I get a black screen. Exiting Big Picture does not show the desktop, but the same black screen.

(Seems that Steam is not streaming the whole monitor but only individuals game windows instead. If I open a game windowed side-by-side with any other application, in the streaming only the game is shown.)

Using Steam beta from Arch Linux repositories.
Pipewire 1:0.3.39-1
sway (wlroots)

This still doesn't seem to work for me unfortunately. I am using the November 11th beta build. I have tried with the -pipewire switch and the -pipewire-dmabuf switch, but neither works correctly. When Steam starts xdg-desktop-portal asks me for permission for screen sharing as expected. I have two monitors, so I have to pick one of them. But no matter which one I select, Steam Big Picture will not show and I will get a black screen instead. Once I start a game I see the screen just fine.

I am using the latest Gnome from Arch repositories.

I managed to get some (hopefully useful!) logs. As I mentioned in my previous comment, my Client's screen is still black when streaming big picture mode. I only see something once I actually launch a game. When I first start Steam with the "-pipewire" flag, I get the question for which screen I want to share from xdg-portal, as expected. Once I select a screen, I see this in my log:

Dec 18 17:09:25 Jaap-Desktop xdg-desktop-por[3091]: Unhandled parent window type 
Dec 18 17:09:25 Jaap-Desktop xdg-desktop-por[3091]: Failed to associate portal window with parent window 

Once I actually connect to Steam from the client, I see this in the logs:

Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: pw.context: params Spa:Enum:ParamId:EnumFormat: 0:0 Invalid argument (input format (no more input formats))
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default: Object: size 184, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Id 2        (Spa:Enum:MediaType:video)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Id 1        (Spa:Enum:MediaSubtype:raw)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:Video:format (131073), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Choice: type Spa:Enum:Choice:Enum, flags 00000000 32 4
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Id 8        (Spa:Enum:VideoFormat:BGRx)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Id 7        (Spa:Enum:VideoFormat:RGBx)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Id 12       (Spa:Enum:VideoFormat:BGRA)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Id 11       (Spa:Enum:VideoFormat:RGBA)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:Video:size (131075), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Choice: type Spa:Enum:Choice:Range, flags 00000000 40 8
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Rectangle 1x1
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Rectangle 1x1
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Rectangle -1x-1
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:Video:modifier (131074), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Long 72057594037927935
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: pw.context: params Spa:Enum:ParamId:EnumFormat: 1:0 Invalid argument (output format (no more input formats))
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default: Object: size 184, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Id 2        (Spa:Enum:MediaType:video)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Id 1        (Spa:Enum:MediaSubtype:raw)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:Video:format (131073), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Id 8        (Spa:Enum:VideoFormat:BGRx)
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:Video:size (131075), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Rectangle 2560x1440
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:Video:framerate (131076), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Fraction 0/1
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:   Prop: key Spa:Pod:Object:Param:Format:Video:maxFramerate (131077), flags 00000000
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:     Choice: type Spa:Enum:Choice:Range, flags 00000000 40 8
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Fraction 9437195/65536
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Fraction 1/1
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: default:       Fraction 9437195/65536
Dec 18 17:10:54 Jaap-Desktop pipewire[1681]: pw.link: (67.0 -> 75.0) negotiating -> error (no more input formats)

Interestingly, I have tried full screen capture with OBS studio via xdg-portal, and this is working just fine. So it's definitely a steam specific issue. Any help? Using the latest Gnome from Arch's repository.

Interesting. I found the following comment on Arch's wiki:

Note: xdg-desktop-portal 1.10.0 fixed a mismatch between specification and implementation of its D-Bus interface. [1] Hence, some clients may not work with xdg-desktop-portal 1.10.0 or newer.

The comment linked to the following merged PR for xdk-desktop-portal: https://github.com/flatpak/xdg-desktop-portal/pull/609

I know that OBS has already fixed said issue, so OBS should work (and it does!). I am unsure if Steam ever implemented changes to be compatible with this xdg-desktop-portal change.

Is there anyone in this topic that is able to see Steam Big picture on their streaming client under Wayland, with xdg-desktop-portal 1.10.0 or higher?

Can people please post:

• What xdg-desktop-portal version they are using
• Whether pipewire streaming works or not

Would appreciate the additional information :)

@Mushoz I am using xdg-desktop-portal-1.10.1-2 under Wayland in Fedora Silverblue and streaming with pipewire.
I cannot see Steam Big picture in the streaming client (green screen with artifacts), but after entering a game the stream is flawless.

I just gave Steam Remote Play another try with Steam being on this version and starting it with the -pipewire argument:

Unfortunately neither the Big Picture mode nor the actual game produces any image at all. On my client i just have a completely black screen.
But at least it doesn't crash anymore ;)
The portal to share the screen pops up tho. It is on version 1.10.1-1

I am using Manjaro Linux with Gnome-Wayland as my desktop.

Was having the black screen problem on latest Manjaro KDE Wayland session. Launching Steam link to desktop or big picture mode was giving me a black screen on both -pipewire and -pipewire-dmabuf. When a game launched, everything worked fine.

However, upon disabling one of my 2 monitors and connecting with steam link, everything worked just fine. Tried multiple times with both 1 monitor and 2 monitor setups and the results were the same.

Edit: Starting up steam with the pipewire flag with 1 monitor enabled and then enabling the other one also works, which is quite odd

Ubuntu 21.10 + Wayland here.
Same problem as previous reports : can't stream Big Picture menu, but I can stream a game launched by BPM (after putting this game in a window, in a resolution equal or lower to the target resolution)

So this bug is definitely not limited to X, but also happens with Wayland : https://github.com/ValveSoftware/steam-for-linux/issues/7130#issuecomment-898869388

I've just tried reproducing this on Arch, and indeed I get the artifacts with xdg-desktop-portal 1.10. With xdg-desktop-portal 1.8.x I get a static screen of the desktop Steam view. However, if I first enter Big Picture and then start streaming, the screen is corrupted as well.

I just tried Steam in-home streaming on my desktop, starting steam with the -pipewire-dmabuf argument:
Using Intel UHD Graphics 630 (I know bleh)
SwayWM, on Arch Linux with the 5.15.21 xanmod kernel.

I was able to launch Rimworld, a Linux native game which runs in XWayland. Like many others said, I had to manually shift focus from Big Picture Mode (by making it windowed) to Rimworld. Rimworld ran in full screen or windowed mode, and the resolution changed appropriately on the client device.

I tried launching Duck Game, a game run through Proton, with Proton Experimental. No matter what I tried, the screen remained black while playing Duck Game. I'm assuming it is specifically Proton or Wine in general that is to blame here.

@eaglesemanation I wanted to thank you and confirm that this solved the black screen issue for me as well. Fedora 34, Wayland session, Steam flatpak, Samsung Smart TV with Steam Link on it. Connecting to the host from TV results in the black screen with the cursor visible. Doing the 2-step procedure as you described fixed the issue.

Hello @kisak-valve can you tell us if this issue is prioritized ?

I assumed it was, as Wayland is more and more widespread, and all Steam Deck are new potential Steam clients for In-home streaming.

Been trying this as well in a sway session on Debian 11 (some packages from testing) with the Steam flatpak (thank you, @eaglesemanation). Same result as for many others though: Desktop and Big Picture just show a black screen, streaming games works. When showing streaming statistics, as soon as the renderer switches from OGL (desktop, Big Picture) to Vulkan (games), everything works as it should. Perhaps the "easy" (?) fix would be to switch to Vulkan for Steam GUI / desktop rendering, too?

You could try running Steam in gamescope (since the output is Vulkan). It partially worked for me but was either unstable or had flickering issues, depending on how it's configured. But YMMV and with some tinkering it may be viable.

There's also Zink (OGL -> Vulkan) although it didn't work at all for me, although I suspect it's a system issue on my end.

However, it appears to worsen the bug affecting monitors not situated at the top-left of the workspace on both axes. If my primary monitor is set to 1080p and configured to the right, the client streams only the last column of pixels stretched across the screen (with the -pipewire-dmabuf option - otherwise it's blacked out). 1440p causes slightly different behavior with a bit more of the right side of the screen being visible.

I just want to bump this since it's still occurring in the same manner in the latest Steam client beta.

Just gave it another try today, without passing -pipewirethe garbled screen issue persists.

Host:
Fedora (gnome+wayland)
AMD RX 570 (Kernel 5.17.1 - Mesa 21.3.8)
Steam Flatpak (beta) (steam package versions: 1648513529)
Steam launched via flatpak run com.valvesoftware.Steam -pipewire
Full system info

Client:
SteamLink device, updated to latest available firmware

Host and Client output photos:
https://imgur.com/a/EjnaaBa

~The client crashes when I start with the -pipewire flag on Sway. This occurs with Steam-runtime and the Flatpak version
System Info~

~I can include the .dmp file if needed :)~

Edit: Fixed by installing lib32-libcanberra on arch

Any news here?

I understand that the Steam Deck is using Wayland for games, so it can't be used as host for In-home Streaming unless this bug is fixed. That is a good incentive for fixing, isn't it ?

Tested again today with sway, PipeWire, wireplumber, xdg-desktop-portal-wlr, flatpak steam -pipewire under debian testing and the issue (-> still image shown at first start; black screen upon next connection; games work) remains. Tested with flatpak OBS and PipeWire screen capture works flawlessly there. Both apps have "xdg-run/pipewire-0" set, if that is even still necessary. Screen selection is set to a fixed (virtual) display and no other screens are connected to the sway session. Any chance to see PipeWire screen capture work for Steam Link streaming sometime soon?

Tested on flatpak, no beta, with help of @eaglesemanation guide, worked quite well. Requires quite good hardware decoding capabilities or else it will be laggy.
Steam link works too but of course is a bit borked (juddering), but that's not remote play issue.

I tested a few things today since Pipewire updated to 0.3.53 and found some interesting results.

Host:
Fedora (KDE Plasma + wayland)
AMD ATI Radeon RX 6800/6800 XT / 6900 XT (Kernel 5.18.9-200 - Mesa 22.1.2)
Steam Flatpak (beta) (steam package versions: 1656367348)
Launch Command: /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=/app/bin/steam-wrapper --file-forwarding com.valvesoftware.Steam -fulldesktopres -pipewire-dmabuf @@u %U @@

Client:
Google Pixel 6 Pro

I have 2 monitors and my main monitor is to the right of the other. I have found that previously when In-Home Steaming with -pipewire-dmabuf, that the receiving device gets a partial view of the actual screen.

Today on the same setup, I found if you select Full Workspace, that the receiving device displays the expected results. (Full view of the main monitor running Big Picture). One issue, which I describe below, is that some games won't stream in fullscreen/borderless.

I also found in a few games, that a frozen frame will appear on the client if the game is fullscreen/borderless. I can tab out and back in to update the single frame, but it will not update further. I found that these games would work after taking them out of fullscreen/borderless. On No Man's Sky and found it would not stream in borderless, or fullscreen, and Katana Zero would work after taking it out of fullscreen. Elden Ring seems to work fine as-is in borderless.

I would be happy to elaborate on anything if needed. I hope others find similar results so that we may work closer to a solution.

I was able to make it work. I'm still unsure how, and I don't have much more time to debug, so I'll write down what I did.

• Server: on sway, Arch Linux, pipewire 0.3.52-2, Mesa 22.1.2, AMD Radeon R9 Fury Series (fiji, LLVM 13.0.1, DRM 3.46, 5.18.6-arch1-1). I use pipewire for audio, and make use of wireplumber. VA-API for hw encoding. Connection: LAN PLC (jittery)
• Client: Galaxy S4 with LineageOS 17.1 without Google Services, hw decoding. Connection: LAN Wi-Fi (far away, 5Ghz).

I had the same issue in the beginning (corrupted output) while following the instructions above (additionnal permission, non-beta update, modified command line), then I tried launching steam again. I never got prompted for a screen, which was weird. I reverted the permission modification, and tried with a normal com.valvesoftware.Steam -pipewire

I then noticed xdg-desktop-portal-wlr (for wlroots, if using a different DE that would be a different portal) pegged to 100% CPU. So I tried to launch a new instance with /usr/lib/xdg-desktop-portal-wlr -r -l INFO (the -r to replace the current instance is standard across portals), but it didn't kill the old one, so I killed it manually, got the prompt to pick a screen, and it has been working since.

I noticed the same garbled output when the client starts streaming before steam gets permission to grab the pipewire stream. qpwgraph might be of interest to keep an eye on the streams.

TL;DR: I restarted the portal with more verbose logging after noticing it was stuck. I didn't need to restart it later.

It now works:

• With and without dma-buf
• With and without steam client beta
• Without the additionnal permission
• With and without hw decoding
• With the normal invocation and the modified one from @Zoarial94 above

Obviously I didn't check every combination, I just toggled each.

Interestingly, I killed my instance of the portal, and relied on it auto-starting, it worked fine. I wonder if everything will still work after a reboot.

Issues:

• On the client, the image is cropped: I cannot see the top, and there is a black bar at the bottom (see screenshots at the bottom). That doesn't seem to affect games, but it seems to affect all pipewire streams).
• the portal spams the following (could be a wlroots issue, or not an issue at all):

  2022/07/07 15:03:55 [WARN] - wlroots: no current buffer
  2022/07/07 15:03:55 [WARN] - pipewire: out of buffers
  2022/07/07 15:03:55 [WARN] - wlroots: no current buffer
  2022/07/07 15:03:55 [WARN] - pipewire: out of buffers
  2022/07/07 15:03:55 [WARN] - wlroots: no current buffer
  

• Steam has a hard time closing for some reason (from the menu bar or context icon): it closes, then opens again, reconnects, and the whole interface is displayed with a serif font. Works as usual otherwise. That happens anytime one of the -pipewire options is used.
• Latency is pretty high, but that could be my network (wi-fi plus PLC, I tried my current set-up upon seing the previous message).
• When I un-fullscreen steam big picture but keep it focused, it seems the stream is cropped and stretched to the client window, but with the wrong area (it isn't big picture that appears on the client, but part of the terminal to its left). Not really an issue if you don't force big picture out of fullscreen. When it isn't focused, I get the whole "desktop" screen as usual.
• Obviously, input doesn't work on wayland clients

I noticed the connection breaking once, could have been due to a network error.

2022/07/07 15:20:28 [WARN] - wlroots: no current buffer
2022/07/07 15:20:28 [INFO] - pipewire: stream state changed to "paused"
2022/07/07 15:20:28 [INFO] - pipewire: node id is 344
2022/07/07 15:20:28 [WARN] - pipewire: no buffer to queue
2022/07/07 15:20:28 [INFO] - pipewire: stream state changed to "unconnected"
2022/07/07 15:20:28 [INFO] - pipewire: node id is -1

"SessionStats"
{
	"ClientDeviceID"		"Samsung GT-I9506"
	"ClientDeviceVersionID"		"Android 10"
	"GameNameID"		"Steam Big Picture"
	"appid"		"413090"
	"TimeSubmitted"		"1657200351"
	"ResolutionX"		"1920"
	"ResolutionY"		"1080"
	"CaptureDescriptionID"		"Desktop PipeWire NV12 + VAAPI H264"
	"DecoderDescriptionID"		"Android texture hardware decoding"
	"BandwidthLimit"		"15000"
	"FramerateLimit"		"0"
	"Transport"		"1"
	"SlowGamePercent"		"0"
	"SlowCapturePercent"		"0"
	"SlowConvertPercent"		"0"
	"SlowEncodePercent"		"0"
	"SlowNetworkPercent"		"13.8925237655639648"
	"SlowDecodePercent"		"0"
	"SlowDisplayPercent"		"0"
	"AvgClientBitrate"		"47.1469841003417969"
	"StdDevClientBitrate"		"16.3850002288818359"
	"AvgServerBitrate"		"1960.9317626953125"
	"StdDevServerBitrate"		"0"
	"AvgLinkBandwidth"		"100000.0078125"
	"AvgPingMS"		"20.1274318695068359"
	"StdDevPingMS"		"18.1399078369140625"
	"AvgCaptureMS"		"20.4270915985107422"
	"StdDevCaptureMS"		"0.780452311038970947"
	"AvgConvertMS"		"0.106260351836681366"
	"StdDevConvertMS"		"0.960966050624847412"
	"AvgEncodeMS"		"13.4462614059448242"
	"StdDevEncodeMS"		"2.62807393074035645"
	"AvgNetworkMS"		"17.2437686920166016"
	"StdDevNetworkMS"		"35.088104248046875"
	"AvgDecodeMS"		"2.21702289581298828"
	"StdDevDecodeMS"		"13.5201148986816406"
	"AvgDisplayMS"		"1696.481689453125"
	"StdDevDisplayMS"		"10127.8251953125"
	"AvgFrameMS"		"100.580650329589844"
	"StdDevFrameMS"		"33.4622764587402344"
	"AvgFPS"		"44.9604301452636719"
	"StdDevFPS"		"22.6070499420166016"
	"BigPicture"		"1"
	"KeyboardMouseInput"		"0"
	"SteamControllerInput"		"0"
	"TouchControllerInput"		"1"
	"GameControllerInput"		"0"
	"XBox360ControllerInput"		"0"
	"XBoxOneControllerInput"		"0"
	"PS3ControllerInput"		"0"
	"PS4ControllerInput"		"0"
	"OtherControllerInput"		"0"
	"WasSpectating"		"0"
	"RemotePlayTogether"		"0"
}

Client Screenshots

Description	Picture
Before selecting a screen from the portal (this used to be all the time)
After selecting a screen as prompted by the portal
Picture from the store. Notice the cropping on both images

I'm still having problems with this:

Operating System: Arch Linux
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.10-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor
Memory: 62.7 Gio of RAM
Graphics Processor: AMD Radeon RX 6900 XT
Mesa: 22.1.3

• With the "--pipewire" flag Steam's BP UI is a black screen
• When launching a game, the game is displayed but the stream framerate is locked to 30fps for some reason
• Steam Link client is Samsung TV which works perfectly under Xorg Steam server

Anyone encountered this? Anyone has a way to make this finaly work again on Wayland?

same im having this issue on fedora 36 with wayland and an nvidia gpu

@m1m1k4tz similar SW setup here. have you tried starting steam client with -pipewire flag? note only one hyphen (IMHO most "linux experienced" users get tricked by this) If you do it right, after you enter password, xdg-desktop-portal pops-up asking you what you want to share (screen/window). Only tested whole screen and it works.

Experiencing some image slutter from time to time but it's usable for couch co-op. Getting better with every wireplumber update.

P.S. sorry for description for somehow reason I can't upload images

edit: I forgot to mention screensaver breaks it all. after then, you have to go all the way from step one (stop/start steam client, as new request for screen sharing will never come)

Operating System: Fedora Linux 36
Kernel Version: 5.18.13-200.fc36.x86_64
Graphics Platform: Wayland
WM: GNOME shell 42.3.1
Processors: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Memory: 15851 MB
Graphics Processor: NVIDIA Corporation NVIDIA GeForce GTX 1060 with Max-Q Design/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 515.57
Mesa: 22.1.4-2

I can also confirm that it now works (at least on my system, Wayland, KDE-Plasma 5.25.4 5.25.3, Kernel 5.18.11). But only if -pipewire is set and only if sharing "Full Workspace" is selected.

@DistantThunder maybe try it again, since your setup is similar.

I get weird issues, I can't stream Windows games (infinite loading screen), but Factorio with native wayland backend works fine.

This is with Sway, -pipewire-dmabuf, dual-monitor setup, and NixOS.

Maybe wlr portal needs improvements, I'll have to investigate further.

at least on my system, Wayland, KDE-Plasma 5.25.4, Kernel 5.18.11

Plasma 5.25.4 has not been yet released. I presume you're talking about 5.25.3?

My setup with Fedora 36, Plasma 5.25.3 and Wayland is broken at this point.

I use one display set vertically (90 degree rotation) and the main (primary) display is a regular 16:9. Trying to stream via Steam Link results in:

• Steam Big Picture being shown partially on the remote. It looks pretty much shifted 1/3 up.
• Steam Big Picture navigation is awfully slow
• Launching games results in a black screen on the remote

When I disable the secondary, vertical screen (which I'd rather not be forced to do anyway) I get:

• Steam Big Picutre properly placed on the remote, however
• Steam Big Picture navigation is awfully slow
• Launching games results in a black screen on the remote

So no success for me.

Since I thought regular Steam Link is broken (and turns out still is) on Wayland, I tested Sunshine. With Moonlight on the remote, of course. It has some bits to tune in my setup, but I'm getting really nice results and I don't have to log out of Wayland session to stream.

It's not ideal since Steam has to be running before I start a session on the remote. And closing Steam and trying to start it again from Moonlight results in some issues. But if I avoid closing Steam between sessions - all good!

I also want to mention that using -pipewire means that... for as long Steam is running, the portal capture is active. This means that e.g. desktop notifications will be suppressed by default on Plasma. If Valve is going to go through with PipeWire, the capture needs to happen only when a remote session is started. And probably only when Big Picture is on.

With Sunshine I don't have to worry about this.

Operating System: Fedora Linux 36
KDE Plasma Version: 5.25.3
KDE Frameworks Version: 5.96.0
Qt Version: 5.15.5
Kernel Version: 5.18.13-200.fc36.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 31.1 GiB of RAM
Graphics Processor: AMD Radeon RX 6600 XT
Manufacturer: ASUS

I know that gamescope has been mentioned couple of times here, but there's not much details on how one can leverage that. I just tested running entire Steam client via gamescope with the following command:

gamescope -f -e -w 3840 -W 3840 -H 2160 -h 2160 -- steam -tenfoot -steamos -fulldesktopres -nointro

(it's a slightly modified version of what GE mentions in his COPR package)

With that, I received a fullscreen window and didn't have to disable my vertical display to use Steam Link. It just works. Steam doesn't have to worry about other displays. It just uses what ever we tell gamescope to emulate.

When quickly tested with DiRT Rally 2.0, I quickly saw many black screens while the game was running. Reverting to "Balanced" instead of "Beautiful" video setting helped.

OT: now I'm wondering whether Steam lacks in some encoding capabilities on Linux or there's something else broken so that my 4K stream can't be stable

With gamescope running as it is, I'm now wondering how much work will it be to run that directly from a headless shell so that instead of running full KDE I could just launch gamescope. That would be super useful when running a "headless" machine, so I will definitely give it a try.

@slagiewka, gamescope serves as a X server (Xwayland) and compositor, as well as a wayland client, as explained there: https://github.com/Plagman/gamescope/issues/130#issuecomment-727893643

Steam doesn't even need to know it isn't on a classical X11 desktop, so while that's an interesting workaround, it doesn't help with this issue.

You might be able to tell more by looking at qpwgraph's output, it should show steam capturing from the portal.

You can probably run it headless with some of the following environment variables: WLR_BACKENDS=headless WLR_LIBINPUT_NO_DEVICES=1. I've seen some sway setups like that.

BTW, I use wireplumber instead of the old pipewire-media-session, and also use pipewire for the audio system. As previously reported, it works, but I only had tested the video. Audio is garbage (high pitched continuous noise).

Tested again today with sway, PipeWire, wireplumber, xdg-desktop-portal-wlr, flatpak steam -pipewire under debian testing and the issue (-> still image shown at first start; black screen upon next connection; games work) remains. Tested with flatpak OBS and PipeWire screen capture works flawlessly there. Both apps have "xdg-run/pipewire-0" set, if that is even still necessary. Screen selection is set to a fixed (virtual) display and no other screens are connected to the sway session.

Tested with the above setup and the -pipewire flag produces the dreaded black screen with the most recent packages, -pipewire-dmabuf shows the stream finally, though unfortunately not at 60 fps, but only at around 45 in Big Picture and games with HW acceleration at 1080p, which doesn't tax the GPU (Vega 8 based APU) much ... at least it wasn't a problem with OBS or Sunshine. SW encoding produces only a black screen and doesn't seem to be an option with either flag. The above with flatpak's Mesa 21.3.9 - the devel branch does not seem to work with HW acceleration (*), switching to SW and in turn leading to a black screen again.

(*) Could this be due to the outdated VA-API 1.12 used by the Steam flatpak package?

Edit: Tested with 720p to make sure that this definitely isn't a performance issue and the fps remained the same using that resolution for streaming.

For me, I get a static screen using hte -pipewire flag. If I press the Super key to show all of the windows, then the window with the game will update

for me it works with the -pipewire flag on the beta flatpak version of the steam client i tried the mesa git drivers from here https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/wikis/Mesa-git but steam started getting buggy so for me its a good tradeoff between stability and newer mesa drivers but the stream is a little buggy on wayland overall if you exit the app sometimes it pops up again with weird fonts im on an amd gpu now too though EDIT: actually i was wrong the beta flatpak version just randomly broke but i just uninstalled it and reinstalled the normal version and i still have all of my stuff and i also checked my system information and the mesa drivers arent version 21 anymore so i think that issue got fixed

i just noticed after the update that improved in home streaming on vulkan games theres a green bar under fallout new vegas when using gamescope rdr2 works fine tho also to get gamescope working for the flatpak version on silverblue 37 i have to use the community build of proton from flatpak not the one preinstalled from steam

is there any way to make streaming comfortable again? I know it needs to be implemented in the client explicitly. Is there progress on the feature? Any ETA?

It has been done before:
https://github.com/obsproject/obs-studio/pull/5559
https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/14
https://github.com/flatpak/xdg-desktop-portal/pull/638

I like to sit on the couch and fire the steam link. Now I have to go to the PC, and make sure to start with -pipewire, and accept the permission screen. This essentially kills wake-on-LAN feature too.

Can confirm this is still an issue on Fedora 37 on GNOME with Wayland using the Flatpak, streaming to a Samsung Galaxy S21. Using -pipewire flag allows screen to be displayed, but the right third of big picture falls off screen.

I've even seen a regression in that it no longer works in X11 either :(

I assume steam client / gpu driver updates broke it. Have reverted back to booting Windows when I want to play on my TV, which makes me sad. I expected this to be more polished since Valve now has the Steam Deck; I assume it runs X and they don't care about Wayland...

The steam -pipewire at least gets the streaming going but after that the streams on two different games I tried would freeze up after loading into the game proper. Title Screen was promising but when I loaded a save and 3D was involved everything froze up on the stream but the game is still playing just fine on the host. (Host: Endeavor OS (arch linux based) with steam beta, AMD CPU, AMD 6800 XT, 32 GB RAM, Plasma on Wayland session) (clients: latest steamlink app on Raspberry Pi OS bullseye, my Surface Book 3 with windows 11 steam beta using remote play) (tested Total War Warhammer 3 native and Frostpunk using Proton Exp) (I need to add versions when I get a chance to be more concise)

Edit: I tested No Man's Sky and it worked well, but the previous mentioned games still do not work and freeze up.

same for me. It is SO SLOW and unusable on any 3D game (ie: Superliminal, Quest Costume 2). I can only play 2D games (if there isn't much movement on screen). In my case the combination is a Steam Link connected to an Intel Xeon (8 threads) with a radeon RX6400 on Ubuntu. I mostly play old games there (I use a console for newer games) so I know the desktop can push 4k on old games (like Dead Space). But even when lowering the resolution to 720p, it works terrible on the steam link. (yes, I know the 1080p limit on the steam link. But it doesn't even work at lower than that and setting it to speed mode, downgrading the quality)

I tested remote play together on wayland and it worked today. i am using steam beta on flatpak. but the steam link didn't work.

Tried Steam Remote Play on Arch Linux, tried streaming Soulcalibur VI. Gamestreaming didn't work until I used the -pipewire flag as it doesn't seem to stream Wayland content without it.

It would load the game, but then it would freeze right when the actual game stage loads and sticks there. Quitting the game causes the entire screen to freeze.

It appears that gamestreaming via Wayland is still quite experimental for Steam on Linux. Using Gamescope didn't make this any better, in fact attempting to stream when Steam is running in Gamescope causes Steam to just crash to desktop.

While trying to stream to Android, have black screen.
At terminal I had this:

ffmpeg verbose: libva: VA-API version 1.16.0
ffmpeg verbose: libva: Trying to open /usr/lib/dri/radeonsi_drv_video.so
ffmpeg verbose: libva: va_openDriver() returns -1
ffmpeg error: Failed to initialise VAAPI connection: -1 (unknown libva error).
CGameStreamVideoStageVAAPI: Failed to create device context: Input/output error

Disable\Enable Hardware Acceleration not helped

Run Steam with -pipewire has same issue

vainfo out:

Trying display: wayland
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.3.5 for AMD Radeon Vega 8 Graphics (raven, LLVM 15.0.7, DRM 3.49, 6.1.11-200.fc37.x86_64)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

System information

Steam client version: 1.0.0.75 (RPM)
Distribution: Fedora 37 GNOME
Wayland: 1.21.0

p.s. Sunshine streaming works great via Wayland

Hello @kisak-valve https://gist.github.com/777Raim/8815db8bb2541ef7ea9e33b83df58a60

Thanks, I founded that there was missing radeonsi_drv_video.so in /usr/lib/dri folder. I installed mesa-va-drivers-freeworld.i686 to add missing files.

After that Steam has this output https://gist.github.com/777Raim/5060f322664ea0dc9cfe25df34d01645

At the Phone I have black screen, but I see the cursor

@deltatux @dc740 @noobmagnet I think I have the same issue as you all, and I managed to find a workaround:
(Apologies as my UI is not in english, so the translations may be wrong)

1. Enable steam beta.
2. "Stream" any 3D game that freeze after it's loaded.
3. Load in the game until it's frozen.
4. Go to the stream overlay (Hold escape on keyboard or hold "back" on controller for 3 seconds)
5. Press "Stop streaming", not "quit game".
6. Press "Connect" on the game you just stopped the stream in.

This worked for me on Sekiro: Shadows die twice. The quality of the stream is abyssmal though. Even with unlimited bandwidth and beautiful enabled, a bitrate of 100mb still looks terrible somehow (Checked by enabling performance information).
Also, this issue seems to not be wayland spesific, as I swithed to gnome xorg on host and it persisted for an xorg, windows and even a steam link phone client.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1445112122

This indeed worked when I was trying out Titanfall 2, although being an action game things love to black out on me at inopportune times lol. It still gets frustrating because the freezes never completely stop, they only stop for a few minutes and then come back and you have to repeat the process.

Installed the latest beta client.

-pipewire or not, I still get black screen when streaming to an Android TV.

It also seems that the client is still X11, but... now it doesn't even scale with the desktop (just a 2x scale). I have also seen it cause Dirt Rally 2.0 drop to 7 FPS on 4K (instead of 90). But this is something for a different report.

I have the same issue: a black screen, but if run the game, then stream works.

Have last beta + Android Steam Link

It's been consistently "working" for me under pipewire with a few caveats:

• you have to "share" a screen with steam every launch
• The FPS in the bigpicture interface is about 0.2FPS 😅
• The capture size is wrong so on my TV I can only see 1/4 of the steam interface
• Sometimes when launching the game steam crashes and I have to start over

once in the game, everything is fine

Streaming seems to work when using the -pipewire flag with the newest beta client. However I think the screen should only be captured when streaming instead of all the time. Also I didn't have access to the big picture overlay anymore when I was in the game. Could be related to switching the resolution in game though.

At least it seems to work for the most part. I had no real issue playing once in the game.

Good news lads, Wayland support just got merged into wine. Maybe one day we'll have native support from the steam app.

Good news lads, Wayland support just got merged into wine. Maybe one day we'll have native support from the steam app.

It wasn't. It's work in progress and only another part was added. Still not there.

Good news lads, Wayland support just got merged into wine. Maybe one day we'll have native support from the steam app.

It wasn't. It's work in progress and only another part was added. Still not there.
Oh, I thought this was the final design but I might be wrong
https://gitlab.winehq.org/wine/wine/-/merge_requests/2712

Oh, I thought this was the final design but I might be wrong
https://gitlab.winehq.org/wine/wine/-/merge_requests/2712

This is the main branch downstream that's trying to merge with the upstream main winehq repo:
https://gitlab.collabora.com/alf/wine/-/tree/wayland/dlls/winewayland.drv

There's still a lot, as you can see. That said, I think you're missing some context.

First of all, the Steam app itself doesn't depend on Wine. Someone correct me if I'm wrong, but I think Steam has its own CEF (Chromium Embedded Framework) and I think uses some Qt component as well (not sure). In addition, it has its own set of dependencies on Steam, which you can see when you're looking up the package info for Steam from package manager and the flathub manifest.

Recently they said that they have worked out a lot of the technical debt they had, and would likely see increased pace of updates. Who knows, they may work out proper xdg-desktop-portals support for screensharing before they release a 64-bit client, considering they did finally worked out portal use for file-picker in the Beta. TeamViewer, Zoom, Chromium, and OBS have managed to work it out, after all, with TeamViewer having unattended access working too.

As far as Proton itself, first of all, considering the amount of work still unmerged, realistically I'd say it'd only be done in 2024 and only make it to Wine stable branch in 10.0 and maybe make it to staging branch sometimes in 9.x cycle, with a full merge in this year being IMHO too optimistic. I think it's possible to be merged for a beta opt-in branch of Proton Experimental somewhere between 3-6 months after it made it to Wine staging, but even then that's still a long time.

I've tested -pipewire-dmabuf and -pipewire, and neither works for me.

• Using Wayland, remote play seems broken
• Using X11 everything works as intended
• If I execute steam with gamescope in a Wayland environment (gamescope -e -- steam -tenfoot -steamos), everything works, too.

So my setup right now is to use Wayland, and switch how I run steam depending on the scenario:

• If I'll be playing in my desktop, I use steam AS IS, no changes or arguments.
• If I'll be playing remotely, I close my regular steam, and launch it with this: /usr/bin/gamescope --nested-width 1920 --nested-height 1080 --nested-refresh 144 --output-width 1920 --output-height 1080 --fullscreen --steam -- /usr/bin/steam-runtime -tenfoot, which allows me to stream games with no issues

This is only a workaround for now :)

@alvaromunoz yes, you are running steam in gamescope, which is an x11 compositor. Nothing too surprising here :)

Could you try if pipewire-based (and xdg-portal based) screensharing works at all in Wayland for you? I am not sure which environment you use, but you need to have the relevant portals installed on your system (xdg-desktop-portal, as well as xdg-desktop-portal-gnome and -gtk if you use GNOME, -kde for KDE, etc).

I would suggest testing with Firefox on this page: https://mozilla.github.io/webrtc-landing/gum_test.html

As well as OBS (available on flathub).

This checklist may be a bit outdated or specific to wlroots-based compositors, but it's a good resource: https://github.com/emersion/xdg-desktop-portal-wlr/wiki/"It-doesn't-work"-Troubleshooting-Checklist

You can observe pipewire streams with helvum or qpwgraph.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1570350985

Thanks for the trick !!
I always had micro-stutters while in-home streaming (with Wayland and Xorg) and never thought about using gamescope to enforce a specific refresh rate (60Hz in my case). I think my micro stutters were present because my PC monitor (on the host) can't use exactly 60.00 Hz as refresh rate, which is the value used by my client's screen.
I wish I knew that in 2017.

It's been like this for 4 years. At this point I'd be happy with a simple workaround, could it be possible to make steam launch BPM (and games launched in BPM) just start a gamescope window by default?

Could you try if pipewire-based (and xdg-portal based) screensharing works at all in Wayland for you? I am not sure which environment you use, but you need to have the relevant portals installed on your system (xdg-desktop-portal, as well as xdg-desktop-portal-gnome and -gtk if you use GNOME, -kde for KDE, etc).

It does work with the link you posted. Firefox is running on Wayland (checked with qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole), and I am able to share my screen:
.

Maybe I'm a bit lost. What is the -pipewire flag supposed to do? I mean, to see if I'm missing something.

Thanks. This shows that everything should be working, and that the problem probably comes from Steam. I think.

When visiting that website with Firefox, the browser should ask you if you want to share your screen, and offer you to "use operating system settings" as the only choice. Then, your desktop environment should present a window or some mechanism for you to confirm that you want to share your screen, and perhaps select a specific app or screen. On KDE, it should look similar to this: https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1176885572

Maybe I'm a bit lost. What is the -pipewire flag supposed to do? I mean, to see if I'm missing something.

When using the -pipewire flag, the same desktop environment pop-up should appear while steam starts, and you should be able to select the whole screen. The image data is then sent over pipewire to Steam, which will keep the connection active (I don't know whether this uses resources). The -pipewire-dmabuf variant is supposed to be more resource-efficient, but a bit more complex to handle for both Steam and desktop environments.

That means Steam is allowed to capture your screen, and receives the video feed, as Firefox did in your screenshot. However, instead of simply displaying it as in the "getUserMedia test page", steam link will compress that data and send it over the network to be displayed remotely.

Now, there are a few things that could lead to issues, and Steam introduced that feature at a time when pipewire (and especially the dma-buf variant) still wasn't widely supported across graphics drivers, compositors/desktop environments, and applications. It's much better now, but I don't know how much the feature has been worked on since.
Things that could cause issues are "DRM modifiers" among others, if you have specific hardware or drivers, as pixels may not be stored the same way in memory. But visually, that should appear as corruption, not black.

Practically speaking, you should see the following when launching Steam in a terminal:

CDesktopCapturePipeWire: Opening DRM render node /dev/dri/renderD128
# After selecting the screen in the DE-provided window:
CDesktopCapturePipeWire: Start signal received.

I just tried it again (sway), it was a bit glitchy with software encoding (works well for a few seconds, then a freeze on the client, as well as a previous frame that keeps popping up with dma-buf), but works pretty well with hardware encoding enabled (AMD GPU, open source drivers). Also steam has trouble quitting if started with these options: it restarts, I have to kill it. This is for the Flatpak version.

Edit: I see you live-editing your post, could you confirm that your DE asks what screen to share when launching with -pipewire?

Testing to connect from an iphone, the audio and controller connect succesfully. The video only streams the mouse pointer over a black screen, and if I move it in the host, it moves in the streaming client. So... yeah, I'm streaming video, just not steam BPM nor proton games.

Same results either running steam or steam -pipewire -pipewire-dmabuf. Only difference is that in the latter, I get a lot of these messages:

CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data

Note: I tested installing lib32-mesa-vdpau and lib32-libva-mesa-driver, rebooted, and launching steam from a terminal to have a log. The result is the same, it seems these 32 bit versions are not used.

This is for the Flatpak version.

Let me test that, since I've been using the one in Arch pacman.

EDIT: same results. But I'll stick with the flatpak for now

Edit: I see you live-editing your post, could you confirm that your DE asks what screen to share when launching with -pipewire?

yeah, I get this screen

And I'm able to confirm I get the same output you get:

CDesktopCapturePipeWire: Opening DRM render node /dev/dri/renderD128
System startup time: 2.41 seconds
CDesktopCapturePipeWire: Start signal received.

And this is what I see on my iPhone (notice that I see the cursor)

I'm not sure if it fits this usecase, but would using xwaylandvideobridge help? In addition to the flatpak, it's in Fedora 38's repo now.

I'm not sure if it fits this usecase, but would using xwaylandvideobridge help? In addition to the flatpak, it's in Fedora 38's repo now.

I just tried it and read about it. The thing is that it helps on sharing windows, but not the full desktop. From https://discuss.kde.org/t/fixing-wayland-xwayland-screen-casting/217/15

is that would it work on whole screen sharing

What I wrote wouldn’t work for that. It’d probably be doable, but a lot more work than just rendering content into a window.

I kinda get brutal crashes using (Hardware) Steamlink on my Nobara (Fedora) distro. X11 works mostly fine... but there is sometimes a bug where you'll be able to "move" the size of the Big Picture Mode Window when streaming. When doing so you might be able to caues your computer to crash (hard). Same goes for using Wayland though that doesn't seem to work at all since it will send a Blackscreen to the TV. Then sometimes (happend during i tried to get it work) playing around with the Steam Menu.. and clicking "stop streaming to steam link" it also caused a hard crash.

@CaptainCoward are you perhaps also using an Intel card with the i915 driver? Because I have the exact same issue with my Arc A770.

I'm using a AMD RX6600.

Hello @CaptainCoward, that reads like a video driver issue. It might be worthwhile to also mention it to your video driver vendor.

Feeling stupid but where do i actually do that? I'm using the amdgpu driver/Mesa. I never had to report anything like that and have no clue where to do that lol.

Feeling stupid but where do i actually do that? I'm using the amdgpu driver/Mesa. I never had to report anything like that and have no clue where to do that lol.

Here: https://gitlab.freedesktop.org/drm/amd/-/issues

But since it effects both an amd card and an intel card I doubt it is a driver issue.

Hello @kisak-valve any progress to share on this? I just tried again on my Samsung TV and I get a black screen with either -pipewire or -pipewire-dmabuf.

Unfortunately, @perroboc workaround doesn't scale too well at 4k as performance tanks.

• /usr/bin/gamescope --nested-width 1920 --nested-height 1080 --nested-refresh 144 --output-width 1920 --output-height 1080 --fullscreen --steam -- /usr/bin/steam-runtime -tenfoot

Testing to connect from an iphone, the audio and controller connect succesfully. The video only streams the mouse pointer over a black screen, and if I move it in the host, it moves in the streaming client. So... yeah, I'm streaming video, just not steam BPM nor proton games.

Same results either running steam or steam -pipewire -pipewire-dmabuf. Only difference is that in the latter, I get a lot of these messages:

CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data

Note: I tested installing lib32-mesa-vdpau and lib32-libva-mesa-driver, rebooted, and launching steam from a terminal to have a log. The result is the same, it seems these 32 bit versions are not used.

For those still interested, I had those exact messages and after installing lib32-libva (on Archlinux) the 32bit radeonsi driver now loads properly and streaming works using -pipewire or -pipewire-dmabuf.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1659413829

Thank you! I can confirm that this indeed fixes the issue, and I'm able to stream to other devices. Thanks!

Also, with this in mind, please check if steam in Arch is not missing any other libraries: https://wiki.archlinux.org/title/Steam/Troubleshooting#Finding_missing_runtime_libraries

Checking this, I had to install:

pacman -S lib32-fontconfig lib32-freetype2 lib32-gdk-pixbuf2 lib32-gtk2 lib32-libice lib32-libnm lib32-libpulse lib32-sdl2 lib32-libva lib32-libvdpau lib32-libudev0-shim lib32-openal lib32-libsm

If I'll be playing remotely, I close my regular steam, and launch it with this: /usr/bin/gamescope --nested-width 1920 --nested-height 1080 --nested-refresh 144 --output-width 1920 --output-height 1080 --fullscreen --steam -- /usr/bin/steam-runtime -tenfoot, which allows me to stream games with no issues

I got this to work with the flatpak version:

1. Get a shell into the flatpak container flatpak run --command=/bin/sh com.valvesoftware.Steam
2. gamescope --nested-width 1920 --nested-height 1080 --nested-refresh 144 --output-width 1920 --output-height 1080 --fullscreen --steam -- steam -tenfoot

Unfortunately I did not manage to get this into a single command. Also when trying to connect in crashes.

Hello @kisak-valve any progress to share on this? I just tried again on my Samsung TV and I get a black screen with either -pipewire or -pipewire-dmabuf.

Unfortunately, @perroboc workaround doesn't scale too well at 4k as performance tanks.

Tapping in on this to say that adding in the -pipewire flag does make this work on my GNOME Wayland session... except that now it flashes an old frame in between the actual frames. Note that when this is running on X11 that is not the case for me anymore.

Not to mention that some games just do not stream the whole window well and just share the screen instead.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1722157902

Do you have an Nvidia card? My boyfriend has the same exact problem with Discord screen sharing from Linux, but not Windows. Frames seem to be captured out of order, or rotating through a buffer in the wrong order. I don't think it's Valve's fault if they're using Pipewire capture.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1722157902

Following up on this I just got it to work as intended without the flashing after installing lib32-mesa-vdpau and lib32-libva-mesa-driver as stated above by @perroboc.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1722162486

No I have an AMD card, should have specified beforehand

Whoops. Maybe the bug is specific to certain Pipewire clients, then. I never have such issues with OBS Studio's Pipewire capture. Maybe the frames pulled out of it are out of order and have timestamps associated with their presentation order? Other than that guess, I got nothing, and will cease posting here unless I have something actually relevant to add again.

Latest steam version (beta and non beta) completely crashes my Arch installation when trying to stream with and without gamescope sessions, even after a full reinstallation of steam (deleting ~/.local/share/Steam and ~/.steam before reinstalling). This happens when connecting from steam link on iOS.

When trying to stream games using my Steam Deck, I get no picture, only audio.

pacman -Syu is up to date, too. Would be glad to share logs, but I don't know which ones.

NV + wayland, Arch, beta steam.

Unfortunately neither pipewire command works, it asks for my display fine but activating streaming causes only audio and my mouse to display on my TV, followed shortly by a crash.

Despite giving it full desktop acccess, it seems like the mouse is stuck to steam? It doesnt move on my tv unless its hovering over steam, maybe its not receiving the full desktop permission?

AMD + KDE + Wayland.
I get video, but no audio. Controls work fine. Launched steam with -pipewire

AMD + KDE + Wayland here (Mesa 23.2.1 / Arch Linux ): Still a black screen in Steam but streaming possible in-game. Same thing for Pipewire OBS capture being fine, screen-sharing being fine in up-to-date Electron app but black screen for Steam itself...

Streaming on Wayland using Gamescope works very well as an alternative. I currently use Sunshine and Moonlight since it has objectively better quality and latency, but it works with Steam as well. Its also nice to set up a separate audio sink that is used directly for the game so that audio is only played through the stream and not the PC.

Streaming on Wayland using Gamescope works very well as an alternative.

Unfortunately it has huge performance problems on anything >1080p on my end.

Just switched to Wayland and running into this. Has this bug seriously not been fixed in 4 years⁈

Same problem here.

Audio and controlling works, but nothing but no image: just a black screen is shown on link. Nvidia, wayfire. @

If you’re on NVidia and on a Wlroots-based compositor, check if screenshare works at all elsewhere. If it doesn’t, your problem is not Steam.

A wlroots problem coredumps the portal because of an unsupported pixel type (the reason I’m not saying ‘a nvidia problem’ here is because wayland specs explicitly support many pixel types, so to my understanding wlroots is not following it properly) if you’re on NVidia. This can be fixed by forcing a pixel type on your compositor if it supports this.

If your compositor does not support setting an specific pixel time (the one I use doesn’t), you can use a hack/patch to ‘fix’ this.

Conciliating self-compiled programs with programs from the repositories is a pain, so what I did for myself was publishing the patched package on my repository for zypper. If you’re also on openSUSE Tumbleweed, feel free to use it too. You’ll need to add the repository with a higher priority and then install libwlroots11 with --allow-vendor-change on your zypper in. Note that this hack can potentially break stuff for other gpus and maybe even break some features on nvidia even tho everything seems to be working fine for me, so use it at your own risk.

Note that you should not have wofi, slurp or bmenu installed. If you do, Steam will show you a menu to select the monitor you wanna share - this will break remote access since you wouldn’t be able to select the monitor if you’re not at home. (Edit: This seems to me something that Steam could fix on their side tho! OBS, for example, only shows the menu once and then selects the monitor automatically - only showing the menu again if you press a ‘change monitor’ button. Steam could implement this by automatically detecting in which output its window is being displayed (if that’s even possible on wayland) and automatically select that monitor to share (note that right now the menu is shown even if only one monitor is connected) instead of asking for the menu every time)

If you’re on NVidia and on a Wlroots-based compositor, check if screenshare works at all elsewhere. If it doesn’t, your problem is not Steam.

I’m not on Nvidia and it does work elsewhere :)

Note that you should not have wofi, slurp or bmenu installed. If you do, Steam will show you a menu to select the monitor you wanna share - this will break remote access since you wouldn’t be able to select the monitor if you’re not at home.

Interesting. I’m not getting any menu. And since you mentioned OBS: that one works flawlessly.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1659413829

I had this problem while having libva (32bit) installed, and had to install the package "libva-compat" aswell. Just if anyone is facing this issue on gentoo.

Same problem here. I tested all the alternatives mentioned.

So I've reinstalled everything, and right now I'm testing steam beta on EndeavourOS (arch based distro), AMD GPU, KDE Plasma 5, Wayland, Pipewire.

Workaround 1: gamescope

gamescope --nested-width 1280 --nested-height 800 --nested-refresh 60 --output-width 1280 --output-height 800 --steam -- /usr/bin/steam-runtime -tenfoot

The gamescope workaround works for most games. I do need to restart my steam deck every time I shut down and restart Steam on my Host/Desktop, otherwise it won't detect it as a streaming host.

From my testing:

• ❌ iOS Steam Link: Black screen. Audio output and controller input work.
• ❌ Elden Ring: Black screen. Audio output and controller input work.
• ✔️ Hades
• ✔️ Baldur's Gate III: Invisible launcher, use --skip-launcher.
• ✔️ Outer Wilds
• ✔️ Cyberpunk 2077: Invisible launcher, use --launcher-skip.
• ✔️ Thumper
• ❌ Star Wars Jedi Survivor: Black screen. Audio output and controller input work.

Workaround 2: -pipewire

steam -pipewire

This works after following the steps in the arch wiki to install missing runtime libraries, which you can list with these commands:

$ cd ~/.steam/root/ubuntu12_32
$ file * | grep ELF | cut -d: -f1 | LD_LIBRARY_PATH=. xargs ldd | grep 'not found' | sort | uniq

From my testing:

• ❌ iOS Steam Link: Black screen. Audio output and controller input work.
• ❌ Elden Ring: Black screen. Audio output and controller input work.
• ✔️ Hades
• ❌ Baldur's Gate III: Black screen. Audio output and controller input work.
• ✔️ Outer Wilds
• ✔️ Cyberpunk 2077: Invisible launcher, use --launcher-skip.
• ✔️ Thumper
• ❌ Star Wars Jedi Survivor: Black screen. Audio output and controller input work.

Err.. something weird is going on though. Just tried to stream without any special parameters, and most games work, proton and native. Both desktop and steam deck are in beta versions.

No workaround: Just run steam

Yeah, this is weird. Games just stream with the same issues as in gamescope BUT TOO DARK, looks like the gamma just dropped to 0. Might be because I have an HDR monitor in my desktop host? In 4K I use STEAM_FORCE_DESKTOPUI_SCALING=2.0 steam

• ❌ iOS Steam Link: Black screen. Audio output and controller input work.
• ❌ Elden Ring: Black screen. Audio output and controller input work.
• ✔️ Hades
• ✔️ Baldur's Gate III: use proton experimental
• ✔️ Outer Wilds
• ✔️ Cyberpunk 2077
• ✔️ Thumper
• ❌ Star Wars Jedi Survivor: Crashed Steam host, game kept running.

Is anyone else able to test this, too?

Good job, Valve! :D

I ran into problems this week trying remote play for the first time.

For context, I'm on Fedora 39 running the RPMFusion version of Steam and trying to remote play on a stock LCD Steamdeck.

Running steam -pipewire helps a lot, but isn't a complete success. Hades works great, but Stray has either given me (1) a black screen with control and audio, (2) a video steam with no control, (3) control and video for ~30 seconds then video freezes, or (4) complete success.

Running just steam as suggested by @perroboc resulted in a black screen with control and audio, for what it's worth.

Regarding Elden Ring: If I disable EAC by skipping the protected launcher, I can stream without issues. Might be because the executable file doesn't change and Steam keeps streaming the first launched executable.

So maybe some games with launchers dont stream because the streamer is stuck in the launcher PID.

• ✔️ Elden Ring: disabled EAC cmd=(%command%); cmd[-1]=eldenring.exe; "${cmd[@]}"
• ✔️ Marvel's Midnight Suns: skip launcher eval $(echo "%command%" | sed "s|2KLauncher/LauncherPatcher\.exe|MidnightSuns/Binaries/Win64/MidnightSuns-Win64-Shipping.exe|")
• ❌ Star Wars Jedi Survivor: Black screen. Audio output and controller input work.
• ❌ Lost in Random (same, EA Launcher)
• ❌ It Takes Two (EA Launcher)
• ❌ Doom Eternal
• ❌ Wolfenstein: The New Order

@banduccm I don't have Stray in my library, but I know it has issues when using different resolutions form the native one (which happens when you stream). PC Gaming Wiki has a set of instructions that might help in this case.

The In-Home Streaming is not connected with any apparent error. The game is started on the host (win11) with no issue, but Steam never connects and closes the stream window after a second (it shows only spinner)

I tried with and without "-pipewire"/"-pipweire-dmabuf".

I'm sometimes getting the next error output:

src/tier0/threadtools.cpp (3017) : Bad thread local

The remote play hardware decoding for the client is disabled.

Steam output

$ steam -pipewire
steam.sh[39104]: Running Steam on arch rolling 64-bit
steam.sh[39104]: STEAM_RUNTIME is enabled automatically
setup.sh[39176]: Steam runtime environment up-to-date!
steam.sh[39104]: Steam client's requirements are satisfied
tid(39228) burning pthread_key_t == 0 so we never use it
[2024-02-11 12:12:58] Startup - updater built Jan 13 2024 00:51:43
[2024-02-11 12:12:58] Startup - Steam Client launched with: '/home/max/.local/share/Steam/ubuntu12_32/steam' '-pipewire'
02/11 12:12:58 Init: Installing breakpad exception handler for appid(steam)/version(1705108172)/tid(39228)
[2024-02-11 12:12:58] Loading cached metrics from disk (/home/max/.local/share/Steam/package/steam_client_metrics.bin)
[2024-02-11 12:12:58] Using the following download hosts for Public, Realm steamglobal
[2024-02-11 12:12:58] 1. https://client-update.akamai.steamstatic.com, /, Realm 'steamglobal', weight was 1000, source = 'update_hosts_cached.vdf'
[2024-02-11 12:12:58] 2. https://cdn.cloudflare.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'update_hosts_cached.vdf'
[2024-02-11 12:12:58] 3. https://cdn.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in'
[2024-02-11 12:12:58] Verifying installation...
[2024-02-11 12:12:58] Verification complete

Steam logging initialized: directory: /home/max/.local/share/Steam/logs

XRRGetOutputInfo Workaround: initialized with override: 0 real: 0xdd8f4dc0
XRRGetCrtcInfo Workaround: initialized with override: 0 real: 0xdd8f3500
steamwebhelper.sh[39263]: Runtime for steamwebhelper: defaulting to /home/max/.local/share/Steam/ubuntu12_64/steam-runtime-heavy
steamwebhelper.sh[39263]: glibc >= 2.34, partially disabling sandbox until CEF supports clone3()
CAppInfoCacheReadFromDiskThread took 27 milliseconds to initialize
Steam Runtime Launch Service: starting steam-runtime-launcher-service
Steam Runtime Launch Service: steam-runtime-launcher-service is running pid 39383
bus_name=com.steampowered.PressureVessel.LaunchAlongsideSteam
BRefreshApplicationsInLibrary 1: 1ms
CDesktopCapturePipeWire: Opening DRM render node /dev/dri/renderD128
BuildCompleteAppOverviewChange: 338 apps
RegisterForAppOverview 1: 18ms
RegisterForAppOverview 2: 18ms
CDesktopCapturePipeWire: Start signal received.
reaping pid: 39734 -- IPC:CSteamEngin
[2024-02-11 12:14:12] Shutdown

vainfo:

vainfo
Trying display: wayland
vainfo: VA-API version: 1.20 (libva 2.20.1)
vainfo: Driver version: Mesa Gallium driver 23.3.5-arch1.1 for AMD Radeon Graphics (radeonsi, gfx1103_r1, LLVM 16.0.6, DRM 3.57, 6.7.4-arch1-1)

In related information, when using Steam over Wayland, every time I boot steam-runtime with pipewire or pipewire-dmabuf (as required to make Remote Play work over WL), the system always requires to reconfigure the screens to be shared, and does not seem to honor the "Allow restoring in future sessions" option:

Any progress on this? I find this issue particularly relevant now that KDE ships wayland as the default session. This is a feature breaking bug, one that doesn't require the users to change anything to encounter. Please fix it and please provide native Wayland support! Your OS uses KDE and it will break the Steam client on the next update!

I'm using plasma 6 Wayland, it works ok without extra arguments, as stated in previous posts. Tested on Fedora 40.

I'm using plasma 6 Wayland, it works ok without extra arguments, as stated in previous posts. Tested on Fedora 40.

It isn't working for sure on iOS devices, like iPads and Apple TVs

I'm using plasma 6 Wayland, it works ok without extra arguments, as stated in previous posts. Tested on Fedora 40.

It isn't working for sure on iOS devices, like iPads and Apple TVs

It does, here:

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2001973704

I guess they fixed it then, I'll try again later. Thanks!

I'm using plasma 6 Wayland, it works ok without extra arguments, as stated in previous posts. Tested on Fedora 40.

Are you saying this issue is fixed? Because I came here because I just see a black screen like others

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2001973704

On Arch it isn't working. I just see a black screen:
https://github.com/ValveSoftware/steam-for-linux/assets/94871794/19920a20-14fb-45d1-82b8-0d7b70b007fb

Are you saying this issue is fixed? Because I came here because I just see a black screen like others

What Desktop Environment and distro are you using? And did you install Steam through its package manager or flatpak?

On Arch it isn't working. I just see a black screen:
https://github.com/ValveSoftware/steam-for-linux/assets/94871794/19920a20-14fb-45d1-82b8-0d7b70b007fb

Back when I used Arch, I fixed it by installing missing libraries: https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-1660537074

Can you check if you're missing any?

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2003586496

I fixed the missing libraries but I still have a black screen

Now the command

file * | grep ELF | cut -d: -f1 | LD_LIBRARY_PATH=. xargs ldd | grep 'not found' | sort | uniq

Shows no missing libraries

In related information, when using Steam over Wayland, every time I boot steam-runtime with pipewire or pipewire-dmabuf (as required to make Remote Play work over WL), the system always requires to reconfigure the screens to be shared, and does not seem to honor the "Allow restoring in future sessions" option:

does anyone know why "Allow restoring in future sessions" seems to not work as expected?
is this something steam has to support?
or is it not working in plasma yet?

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2014745324

It’s a plasma 5 quirk. That dialog doesn’t appear in plasma 6.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2014787703

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2014794418

Have you tried to run it without those arguments? (pipewire or pipewire-dmabuf). Do you have xwaylandvideobridge? Have you checked if you have any missing libraries? Have you tested the flatpak?

I can tell you, at least in fedora 40, that dialog doesn’t appear when home streaming, I don’t even need those arguments, and I understand xwaylandvideobridge comes by default.

Does anyone know if there is a possibility to persist the permission on gnome permanently?

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2014817712

I'm currently using Garuda Linux (based on Arch) and ensured to have xwaylandvideobridge and all missing libraries installed. I tried running without pipewire and it shows a black screen, but it does also pass sound and inputs through.

Hey to all the "why does it not persist the screensharing" comments: There is a feature request to exactly implement this behaviour:

#10134

As far as i know, this was implemented before the restore option was merged.

Here's my setup:



Steam installed in fedora from rpmfusion repo (dnf install steam)

Here's the evidence it works OK without extra arguments:

https://github.com/ValveSoftware/steam-for-linux/assets/2722773/35b8e64d-f37f-4782-9611-829643a24eca

For me on Exherbo Linux it also worked straight out of the box on KDE Plasma 6 just logging in to a wayland session instead of x11 (no further manual steps were required, no parameters needed to be passed to the steam client, no screensharing dialogs appearing that had to be approved). Like @perroboc above I'm also opted in to the Steam client beta but for other reasons not related to wayland though.

I didn't have the opportunity to test this on NVIDIA yet though, so not sure if it just works the same way with NVIDIA instead of AMD/mesa.

I wonder if Fedora comes with a default setting that Arch does not include. I'm still having problems displaying the screen over Wayland, with Pipewire or otherwise. (Maybe relevant, but I also have Sunshine enabled as a backup, could it be that Sunshine is overriding Steam Link somehow?)

Are you saying this issue is fixed? Because I came here because I just see a black screen like others

What Desktop Environment and distro are you using? And did you install Steam through its package manager or flatpak?

NixOS Unstable with GNOME. Steam is through the NixOS module/nix pkg manager. There are no missing libraries when using the command you listed earlier in the thread.

Arch, plasma 6, pipewire, xwaylandvideobridge, etc.

Streaming now actually works on wayland without any extra arguments, but its a bit quirky? When a game or BPM isnt booted/focused, steam link now shows this live broadcast please stand by screen that i've never seen before, I guess it cant show the wayland desktop without permission? Once a game starts the screen goes away and the game streams fine.

BPM is also still super unusable on wayland Nvidia, still slow as hell and buggy, opening the side menu kills the stream as I guess its not technically a part of the big picture window? Or its because its broken and displays the window behind due to poor spacing.

Here's my setup: [snip]

Single or multi monitor setup?

@csolisr as you mentioned/asked, I also have the sunshine daemon running in userspace (systemctl status --user sunshine) and it doesn't interfere, of course streaming from both at the same time might, that's something I have not yet tested, but only having the daemon idleing doesn't cause any issue here.

@Bitwolfies looks like xwaylandvideobridge isn't required, at least I don't have that package installed (and never heard of it before). So as long as it's still a separate package and not shipped with e.g. kwin or something that package isn't present here. I also noticed the live broadcast screen appearing for a moment that I had also never seen before, probably like you mentioned when things are not focused / starting. The menu of BPM is very odd, it kinda works for me but looks like it's not part of the big picture window like you mentioned, it displays more or less like on the steam deck just broken and not an overlay but a separate "window" or whatever you can call it. Another thing I've come across is text inputs like when starting a new game in elden ring which requires you to enter a name for your character, the "popup" to do so is also not streamed and had to be done infront of the computer with a regular screen. Can't say anything bad about the performance at the moment though, while on X11 it kinda felt more laggy it appears to actually run smoother on wayland (on mesa/AMD at least). Overall I'm with you with your description of it being "quirky" but at least for me BPM has always had its quirks here and there on X11 as well. So things like the input overlay in elden ring I can only report because I tested it on wayland but maybe it's an issue on X11 as well. For now I'm quite happy it works at all on wayland as that was my last main showstopper switching over from X11 now that the horrible fractional scaling on wayland also has been fixed with KDE Plasma 6.

@alterNERDtive can't talk for @perroboc but only for myself, I have a single screen but another "fake" one with an HDMI EDID dongle which is set to the same resolution as my actual physical screen and to clone mode so I can switch off my physical computer screen when streaming without things turning into a slideshow and without wasting additional power and clocking screen time on the display while noone sits infront of it. That appears to work well for me.

I got the sneaking suspicion that it works fine for single monitor setups and breaks with multiple.

I got the sneaking suspicion that it works fine for single monitor setups and breaks with multiple.

It works great too in multi monitor setups. More proof with 2 4k monitors:

https://github.com/ValveSoftware/steam-for-linux/assets/2722773/ea0d355e-17ab-44e3-9c2b-7005b271408f

@csolisr as you mentioned/asked, I also have the sunshine daemon running in userspace (systemctl status --user sunshine) and it doesn't interfere, of course streaming from both at the same time might, that's something I have not yet tested, but only having the daemon idleing doesn't cause any issue here.

Thanks for the confirmation - I was planning to uninstall Sunshine entirely to see if that was the issue.

@alterNERDtive can't talk for @perroboc but only for myself, I have a single screen but another "fake" one with an HDMI EDID dongle which is set to the same resolution as my actual physical screen and to clone mode so I can switch off my physical computer screen when streaming without things turning into a slideshow and without wasting additional power and clocking screen time on the display while noone sits infront of it. That appears to work well for me.

In related news, I have a EDID dongle, but I've tried both with and without it, same issue unfortunately.

Here's my setup:
...

I can second/confirm that it works with the current Steam Beta, but not without. I'm on Fedora 39 (Kinoite, so the KDE Atomic version). The latest steam installed from RPMFusion doesn't show the Big Picture when remoting to a 1920x1080 machine from a SteamLink, though games can be started and work fine. Switching to the Beta channel of Steam in the Steam app settings makes the Big Picture show up as expected on the remote Steam Link.

My system:

FTR I’m not using the beta channel (and it doesn’t work); can’t test right now, but if it works reliably in the beta that sounds promising.

If it helps, I used Xephyr to start an X server in a window and launched steam in that. Steam Link worked perfectly fine like that.

I'm running stock Fedora 39 (Gnome) with Steam installed from DNF.

Everything works great on X11, but when I switch to a Wayland session, All I get streaming to my Steamlink hardware is a black screen with the default mouse cursor in the center of it. I know Steam BPM is running because while the mouse cursor doesn't move, I'm able to blindly move through Steam BPM UI with my controller. I can even launch a game, and I will hear the game audio as though it is running and sitting on the title screen. Oddly enough, the default mouse cursor will even switch to the mouse cursor used by the game, but it remains fixed in the center of a black screen.

I tried installing Xwaylandvideobridge, but this doesn't work...

To my knowledge, pipewire and pipewire-dmabuf are default with Steam, so I haven't tried those...

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2024123257

Have you tested Steam Beta?

Replying to [#6148 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2024123257)

Have you tested Steam Beta?

@mwpow3ll You should. It fixed everything for me plus it added a Please Stand By message that pops up when the Big Picture window is out of focus.

My only problem was switching back to the Steam UI from the game. Holding the Steam button and Tab did nothing, and I had to intervene myself on the computer.

It sorta works on my End. However if i "minimize" steam which i do regulary to stream movies for example i'll get "live broadcast please stand by" on my TV. And i can't seem to do anything. Which makes it pretty much unusable for me. Any clue why is that? I also can't press a "steam button" since i'm using a small keyboard for my TV.

Any clue why is that?

It's because an xwayland application such as steam is not allowed to just capture the wayland desktop. It has to go through pipewire, and then the user will be prompted to select if and what to share. There is some experimental support for this which can be enabled by launching steam with the -pipewire argument. However when I tried this on my system it worked rather poorly, it was slow, crashed, and there were a bunch of graphical artifacts.

Ty that's really sad. So i'm pretty much stuck to x11. Is there actually anything that can be done when seeing the "stand by" message? It seems like everytime i see it i have to go to the computer to get rid of it? Maybe i should try to add firefox as a non-steam game and see if that works lol.

However if i "minimize" steam which i do regulary to stream movies for example i'll get "live broadcast please stand by" on my TV. And i can't seem to do anything.

@YoinkerBoinker For your usecase a look at Sunshine/Moonlight might be worth a try as it offers to select streaming the desktop in addition to e.g. individual applications like Steam (Big Picture) and also works on wayland (utilizing dmabuf/kmsgrab as far as I understand):

Replying to [#6148 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2024123257)

Have you tested Steam Beta?

@mwpow3ll You should. It fixed everything for me plus it added a Please Stand By message that pops up when the Big Picture window is out of focus.

Also confirmed fixed for me, Fedora 39 plasma Wayland, 6700xt. Steam link is working flawlessly on the most recent beta client.

Same as the above, Fedora 39 with Plasma 5.27 has Steam Link working on Steam Client Beta (Flatpak) on an RX 5700 XT. The only thing I've noticed is that launching big picture takes a considerable amount of time when launching from the button in the client for the first time of a session, but it is fully functional if you wait a minute or so. Launching "flatpak run com.valvesoftware.Steam -bigpicture" or selecting stream in the Steam Link app allows big picture to launch almost immediately, not sure what the difference is.

Plasma, Wayland. Before I was able to get games going using gamescope, now I can only get portal streaming.. SteamUI streams also. Switching to X is not an option!
ps, beta steam doesn't fix anything. Don't fall for the comments.
ps2, it's terrible.

My setup is that I normally use Steam Link on Wayland, however if something happens, then I use Moonlight to fix any problems then I go back to Steam Link

Pipewire should have an option where you can permanently give screen access to a specific program.

Capture apps request access to a opaque capture device, pipewire facilitates the communication and routing of video and audio streams, but like with sound, it doesn't actually produce or consume a video stream, that's for pipewire clients, It's up to your Wayland window manager via a xdg-desktop-portal to handle requests and create a capture source, the protocol supports the ability reuse old sessions, it's up to your portal and Steam to handle session reuse correctly though.

common portals:
GNOME xdg-desktop-portal-gnome
KDE xdg-desktop-portal-kde

The reason I still use Xorg is because when I'm running Minecraft: Java Edition from Steam Wayland, Steam Link will stay at "Please Stand By" until I select a game from the Minecraft Launcher.

Pipewire should have an option where you can permanently give screen access to a specific program.

It's definitely supported in GNOME. Works with OBS for me.

Pipewire should have an option where you can permanently give screen access to a specific program.

That’s your xdg-desktop-portal’s job. Open an issue (or even better: pull request) to the portal you use requesting this feature.

Depending on your portal you might also be able to make a script for that. For instance, wlroots’ xdg-desktop-portal-wlr let’s you change the selection menu from dmenu to literally anything else - such as your own script that makes some checks before asking or automatically allowing and automatically choosing a monitor. I was initially planning to do that, but wlroots sucks and works like shit so I just stopped using it and migrated back to x11 and compiz before getting to it (at least until I can do something with smithay myself or something). Still, if you can get the program that’s requesting your screen then the script would be pretty straightforward. Not sure how this works on other portals, but you could always open an issue to yours if one doesn’t exist already.

Back on topic: Current stable release works fine using Wayland on Plasma 6. I was able to stream Hades just fine.

There's no need to use Beta version.

Using Fedora 40, Plasma 6, Wayland, AMDGPU.

Steam Beta Branch:  Stable Client
Steam Version:  1716584667
Steam Client Build Date:  Fri, May 24 4:48 PM UTC -08:00
Steam Web Build Date:  Fri, May 24 4:31 PM UTC -08:00
Steam API Version:  SteamClient021

Operating System: Fedora Linux 40
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1
Kernel Version: 6.8.11-300.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor
Memory: 31,0 GiB of RAM
Graphics Processor: AMD Radeon RX 7900 XTX
Manufacturer: ASUS

That said, are we sure that the original problem in this issue even still exists?

Admittedly I haven’t used wayland in a while, but when I did I never had a problem that was caused by Steam. Everything worked fine for me from the Steam side, as long as it was launched with -pipewire.
Of course, wlroots was (and still is) a problem and you have to apply a hack/patch in order for it to work (and good luck opening an issue about that on their tracker), but then again that’s not a Steam issue. Just use a window manager that’s based on an actually good library and you’ll be fine. There are some really cool wms coming out using smithay these days.

What I mean is that this issue miiiiiight be ready to be closed imo, if no one is having a problem actually caused by Steam.

With this setup:

Steam Beta Branch:  Stable Client
Steam Version:  1716584667
Steam Client Build Date:  Fri, May 24 22:48 UTC -08:00
Steam Web Build Date:  Fri, May 24 22:31 UTC -08:00
Steam API Version:  SteamClient021

Operating System: Manjaro Linux 
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.3-3-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor
Memory: 62,7 GiB of RAM
Graphics Processor: AMD Radeon RX 6700 XT
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: X570 AORUS PRO
System Version: -CF

running steam without pipewire, i can stream the big picture UI fine, but as soon as focus shifts to a started game or i alt tab to anything else, i just get the "please stand by" screen until i refocus the steam window

interestingly, with pipewire i still always get the screen capture select popup, but the permission seems to be remembered, because streaming works fine without interacting with the popup

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2165154095

In last year and early this year, I played Elden Ring about 200 hours without problems by streaming it with Steam Link, by using Wayland + sway and pipewire. Now, with new UI and this "broadcast" window, it just stopped working. It just wants to stream the content of this "broadcast" window, which has just the abort game button. BigUI seems to still work, but it no more wants to stream anything else.

Does anyone happen to know how I can make KDE automatically accept steam's request for screen sharing? I can't really accept it if I'm not at home, and if i wasn'þ at home I wouldn't be using steam link lmao

In KDE's popup there's an option that says like "allow this to be restored in next sessions" or something, but that changes nothing.

Uh, but actually now (at least on NixOS) if I launch steam with -pipewire it will crash as soon as I try to connect to Steam Link
(this also happens on X11 idf I launch with -pipewire, but on X11 without -pipewire Steam Link works fine. On Wayland -pipewire is needed, and with -pipewire steam will crash as soon as I connect to Steam Link)

steam-pipewire-coredump-wayland.txt
steam-pipewire-coredump-x11.txt
steam-logs-pipewire-segfault.tar.gz

Uh, but actually now (at least on NixOS) if I launch steam with -pipewire it will crash as soon as I try to connect to Steam Link (this also happens on X11 idf I launch with -pipewire, but on X11 without -pipewire Steam Link works fine. On Wayland -pipewire is needed, and with -pipewire steam will crash as soon as I connect to Steam Link)

I'm running Steam on NixOS (unstable) and I don't have this problem. Wayland without -pipewire works fine for me, although I do get the KDE Plasma prompt to approve screen sharing. (Not a problem for me, since I only use this to stream from office PC to living room TV.)

Running KDE Plasma 6, running Steam with -pipewire launches an xdg-portal window, of which I select my full workspace. Afterwards I can stream just fine, but the stream is visually unusable due to a framerate of around 0.2fps

Without -pipewire most apps cannot be captured.

For me using the -pipewire option i get these showing up in the logs, is this a issue to worry about or report somewhere like pipewire?

Steam big picture is also funky with this capture and if i move my cursor over to my second monitor and left click the screen goes black on the phone im streaming it too until i click back on the main monitor its trying to capture

And for me exiting out of big picture onto desktop lands on a black screen also on my phone it is streaming too

This is a Ryzen 7600, RX 6700, Cachyos, Kernel 6.12.8, Mesa 24.3.3

Just testing anyways as sunshine + moonlight works great on wayland

CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data
CDesktopCapturePipeWire: Couldn't import dmabuf: Function not implemented
CDesktopCapturePipeWire: Failed to mmap memory: Operation not permitted
CDesktopCapturePipeWire: Couldn't get image data

It is insane that this bug has not been fixed after so many years.

I have abandoned trying to get this to work reliably. Sunshine/moonlight provide a much better experience overall, with more up front configuration but support is regularly provided and bugs are regularly fixed. Works in both X11 and Wayland, also supports many other custom configuration options as well as pre/post connect script functionality to do almost anything else necessary. I use these for scripts to turn off the local monitor when streaming, as an example. Sunshineapp.lizardbyte.devPlay Your PC Games Remotelymoonlight-stream.orgOn Jan 9, 2025, at 2:01 PM, Stelios Katsanevakis @.***> wrote:
It is insane that this bug has not been fixed after so many years.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

I am having the same issue with Fedora 41 Gnome Edition and a NVIDIA 4070 TI in 2025. 🙁

I wanted to switch to Linux for Gaming and to use Steam Link but after 2 days of trying to get Steam Link to work I am giving up. Moonlight is not an option for me, since I experience a lot of PS5 controller issues on my Apple TV which I do no have with Steam Link under a Windows environment. I hope this gets fixed since Wayland seems to become the standard.

I can connect to steam through my Apple TV and it plays pretty well and I don't get any approval prompts either...
But before connecting, make sure the display is turned on (login to your DE session) otherwise you won't get good performance.
Other than that I've just disabled hardware acceleration in steam for Web View in Settings.

CachyOS, KDE 6, Nvidia RTX 4070, driver 565.77

Just thought I'd share my thoughts and experience here with Wayland and Steam game streaming, my gpu being an AMD Radeon RX 7900 XTX on Fedora 41. Sunshine and Moonlight didn't work well for me I only got my desktop when selecting to launch Steam, but I think I found sort of a work around for Steam streaming and Steam Connect.

1. I found that when I launch Steam with the -pipewire flag and then tell which monitor I wanted to share. That then I could Stream Steam from my Nvidia Shield with Steam Connect but it Steam Big picture mode being really laggy, I then launched a game and the game would be really laggy as well. So a not a good experience.

2. After this I would quit the game and quite Steam. Then I would launch Steam normally so without the -pipewire flag. After which I would use Steam Connect from my Nvidia Shield again and this time I had normal reaction time when pressing buttons on my controller and from my tv, then I would pick the game I launced earlier and now it the experience was perfectly normal without experience lag.

I did notice one time that even with this that one game I would get a black screen after having launched the game but before launching the game I would be in big picture mode with a normal user experience, as in how you expect it to be . However when I repeated what I did before again, so what I mentioned in step 1 and then launched the other game again it would be a perfect no lag experience again and playable as if I was sitting at my pc. Then I launched another game which I hadn't launced before and then this launched with no lag and playable as if I was sitting at m pc. So it seems like after having launched a game once without getting lag then the times you launch it after that are a good experiences as well so without lag.

It's an acceptable work around for me, if it gives me an experience where my Stream games are playable with a good experience on Wayland as in in results in an a stream experience which everything feels normal as it should be. I don't quite understand why this works but I would be curious to know what other people's experiences are with this work around that works for me?

Thank you for your response. I’m genuinely impressed by how far Linux gaming has come since I last gave it a try. Almost everything worked seamlessly out of the box—Mangohud, OpenRGB, Secure Boot (at least on Fedora), and even signed Nvidia drivers. I was fully prepared to at least keep Linux installed on a second SSD.

However,
Steam Link became a dealbreaker. Even if I managed to get it running without encountering a black screen, the lack of a Steam Audio Driver for Linux PipeWire—and therefore the inability to achieve 5.1 audio—completely derailed my plans. I really hope Steam addresses this issue in the future. Is there already a feature request open for it?

We are now in 2025. This issue was opened in March 2019—six years ago—and still no solution has been provided.

Could we get an update on what's happening? Valve has made significant contributions to Linux gaming, yet this issue remains unresolved. This is a dealbreaker for many users. I own a Steam Deck and would like to stream properly from my Linux desktop. Most desktop environments now run on Wayland, and X.org has been deprecated by Red Hat and will likely be deprecated by many other upstream distributions soon.

Any official news regarding this topic ?

We are now in 2025. This issue was opened in March 2019—six years ago—and still no solution has been provided.

Could we get an update on what's happening? Valve has made significant contributions to Linux gaming, yet this issue remains unresolved. This is a dealbreaker for many users. I own a Steam Deck and would like to stream properly from my Linux desktop. Most desktop environments now run on Wayland, and X.org has been deprecated by Red Hat and will likely be deprecated by many other upstream distributions soon.

Any official news regarding this topic ?

There isn't much news, the solution for now is to use sunshine + moonlight if you have problems and you can launch steam big picture with the moonlight app also, you just need to allow the firewall ports and that's it

Yeah, Sunshine should work. I find it runs slightly better than the Steam streaming (if you have that working).

We are now in 2025. This issue was opened in March 2019—six years ago—and still no solution has been provided.

Could we get an update on what's happening? Valve has made significant contributions to Linux gaming, yet this issue remains unresolved. This is a dealbreaker for many users. I own a Steam Deck and would like to stream properly from my Linux desktop. Most desktop environments now run on Wayland, and X.org has been deprecated by Red Hat and will likely be deprecated by many other upstream distributions soon.

Any official news regarding this topic ?

I've had success with many games, more than a couple years ago. It's been improving, but it's not quite there yet.

What games have you been having trouble with? For example, in my case (Fedora 41 KDE + flatpak steam) it just works for single window games (Hades), but not for games with launchers or EAC (Elden ring), since the app to track changes in the latter.

Maybe if you share what games you have trouble with, then Valve (or us, the community) could look into it. Also, remember to enable the beta release!

I have the same issue on arch with kde plasma and wayland. Streaming games to my steam link works like a charm but sharing the desktop (aka minimizing steam big picture) leads to a black screen. Works on X11 tho.

Same for me on Arch Linux, this is a shame since Steam is the most convenient way to share my desktop with other people rather than Sunshine, I had many many problems with Sunshine including on Wayland, it only works on X11 just like Steam. I hope Valve add support for the entire display capture soon on Wayland, Xorg is getting removed on many distros and DEs.

Same for me on Arch Linux, this is a shame since Steam is the most convenient way to share my desktop with other people rather than Sunshine, I had many many problems with Sunshine including on Wayland, it only works on X11 just like Steam. I hope Valve add support for the entire display capture soon on Wayland, Xorg is getting removed on many distros and DEs.

When was the last time that you tried sunshine? For me on KDE plasma Wayland, I have zero problems with it for atleast 6 months now

When was the last time that you tried sunshine? For me on KDE plasma Wayland, I have zero problems with it for atleast 6 months now

I tried a month ago I think, not sure, but was pretty recently, it was saying that a protocol on wayland was missing and it also didn't find my gpu drivers or something like that, I do not remember the logs right now.

When was the last time that you tried sunshine? For me on KDE plasma Wayland, I have zero problems with it for atleast 6 months now

I tried a month ago I think, not sure, but was pretty recently, it was saying that a protocol on wayland was missing and it also didn't find my gpu drivers or something like that, I do not remember the logs right now.

Just wanted to confirm that Sunshine is running well under GNOME Wayland session. I even managed to run Steam via xwayland, although it wasn't the smoothest experience. Perhaps you need to deal with display capture settings, or GPU driver, or maybe session params.

When was the last time that you tried sunshine? For me on KDE plasma Wayland, I have zero problems with it for atleast 6 months now

I tried a month ago I think, not sure, but was pretty recently, it was saying that a protocol on wayland was missing and it also didn't find my gpu drivers or something like that, I do not remember the logs right now.

More minimalist DEs/WMs don't include a lot of "nonstandard" or "de-facto" Wayland protocols. Things are really dour for compatibility on Wayland's end.

I'm agreeing with the crowd on the "just use Sunshine/Moonlight" front. It's been my daily driver for remote desktop for a while now, especially since you can install Moonlight as an app on the Steam Link. I'd like a more native solution that lets me use all available controls with Steam Input but this suffices for now.

Streaming is working for me, but always have to authorize screenshare on host PC. I'm using Manjaro and Steam Flatpak.

Using Fedora 41 with GNOME on Wayland, I get lag and a black screen like most of you. A window to authorize streaming pops up on the host, but giving it the go-ahead isn't enough to make it start working. I didn't bother to launch a game since the delay and framerate were too much. Audio played through the host's speakers instead of the device running Steam Link, despite the setting enabled for muting the host.

After ending atreaming, the Steam desktop UI is scaled significantly larger than it should be and doesn't return to normal without exiting and reopening Steam. That part could be related to my use of fractional scaling, but that's just conjecture.

Sitting on Fedora, latest, fully updated. The Steam interface is blank, however, game streaming itself works fine and as expected after clicking past the, aforementioned in thread, authorization modal window. So, in a sense, game streaming works, but I have do any of the interacting with the Steam interface stuff on the computer.

I have exactly same behavior on OpenMandriva Plasma 6 Wayland session, streaming big picture and games are working ok, but desktop sharing is just black screen and moving cursor. Plasma 6 X11 session are working correctly. Desktop streaming through a steam link is my daily usecase - so I need to relog with X11 just for this each time, I hope that this still can be solved somehow.

Same issue here. I have EndeavourOS with KDE and Wayland. I can stream games from it to my phone etc.

The games work fine but when I press the steam button to open the side menu the screen goes black(without a game running, works fine if a game is running). Same thing happens if the cursor moves to another screen or if I run a game with the PROTON_ENABLE_WAYLAND=1 launch option in Proton 10.

Sometimes I get that weird corrupted looking screen but I’m not sure what is causing that.

Maybe the issue with the screen going black when opening the menu is related to me having multiple monitors?

I'm on steam deck and game streaming "non-steam-games" doesn't work even in desktop mode where I could authorize it. Just a black screen as well.

I'm on steam deck and game streaming "non-steam-games" doesn't work even in desktop mode where I could authorize it. Just a black screen as well.

it'll work but only when streaming to a quest vr headset.

We still don't have a fix ? we're 6 years later... Xorg is dying and is not viable on some devices (like my laptop) it would be nice to have at least a working workaround.

We still don't have a fix ? we're 6 years later... Xorg is dying and is not viable on some devices (like my laptop) it would be nice to have at least a working workaround.

I think once the cef wayland problem is solved either by other people fixing it or valve themselves solving it, valves team will start transitioning to wayland with the steam client and that will include getting this stuff working under it properly aswell.

For now sunshine is a great replacement :)

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-2984120144

Yeah I managed to get it working using some flatseal settings but it's kinda janky. and the popup breaks streaming from time to time.

Unfortunately Sunshine doesn't work on my distro properly so it's a no go for me :/ (broken packages versions)

We still don't have a fix ? we're 6 years later... Xorg is dying and is not viable on some devices (like my laptop) it would be nice to have at least a working workaround.

I think once the cef wayland problem is solved either by other people fixing it or valve themselves solving it, valves team will start transitioning to wayland with the steam client and that will include getting this stuff working under it properly aswell.

For now sunshine is a great replacement :)

Not to shit on Valve, they're doing incredible work, but given that they almost single-handedly made Linux gaming mainstream it's unbelievable that they didn't fix this yet - it's not that streaming is a niche feature that no one uses either, so I really don't get why this hasn't received any attention on their end ...

On Bluefin (Fedora Silverblue) flatseal solution doesn't work. Steam starts properly with -pipewire but as soon as you try streaming, system freezes.

Steam link works fine most of the time but there are a few things that doesn't work properly without this is fixed (I think):

• When you open steam menu in streaming, I only see a black screen. I think it triggers some sort of desktop view.
• Some games (even though rare) triggers the same problem and doesn't show at all.

Coming across this issue as I'm trying to play some games on a KDE Plasma 6 installation w/ Wayland on Arch. These games do not have official English translations and am relying on an overlay to display machine translations. I've been using Steam Link on Windows, which supports trivial Alt-Tabbing to display the full screen, but this doesn't work in this Linux system. Trying to alt-tab shows a black screen, the audio works, but no display at all.

X is being used less and less and Wayland is now the default on the majority of Distros.

Any news on a possible solution?

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-3504466933

On Steam's side, no, the only solution is to use Sunshine as other ppl already said, if you want to stream to another person you'll also need Tailscale or Zerotier to make the connection, personally I'm using Apollo which is a fork of Sunshine with some fixes, I'm using in pair with Tailscale and it's working flawlessly

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-3505965407

This is not true. The problem has been addressed and this bug has been fixed. Install SteamLink flatpak, and use a modern distro (i.e. Ubuntu 25.10 or Kde Fedora 42) and SteamLink works fine on wayland. This bug can be closed

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-3506532590

What are you even talking about? Downloading Steam Link on Flatpak gives you the client, not the server…

And no, Steam Link to Wayland machines is very much not fixed. You still need to launch steam with -pipewire explicitly, and even so you still need to allow steam to grab the screen every single time so it just entirely loses the point of remote access. And yes, I do believe that somehow this is something on Steam’s side to fix because it just doesn’t happen with OBS - somehow OBS only needs to ask for permission once. And even with all of that, it is still hugely unreliable and you can’t always get it to work.

It is true that people made so this issue became like 100 different issues in one, but Steam Linking to a Wayland machine is not usable or reliable at all right now.

So to confirm, you're you're using the Steam client on one of the only officially supported platforms:

1. The .deb from steampowered.com on Ubuntu
   2. The Steam client flatpak from flathub

And you you're using the official version of SteamLink from Valve on Flathub?

If you're using the officially supported versions of these applications, then SteamLink on Wayland does work on modern Gnome and KDE desktops on Ubuntu LTS. Which again, is the only officially supported distro from Valve. Can you confirm that this is your setup?

EDIT: The flatpak is not officially supported (I stand corrected.)

I honestly don’t know what the issue is anymore!? I can stream games just fine to my Apple TV with steam running on wayland. I don’t use the flatpak version.
Am I missing something here?

I also don't need the -pipewire argument anymore to have a fully working steaming from Sway (wlroots) to Steam Deck. Worse, using this arg break the streaming. Audio routing works great too. Am using the flatpak steam on Alpine Linux Edge. That being said, this is not a robust feature, and sometime you have to restart Steam/Steamdeck/machines/yourhouse.

Running Fedora 43(Wayland) and I'm getting this issue when trying to stream games from my host using the RPM. This was the same in all distros where I used Wayland (NixOS/CachyOS/ElementaryOS/Bazzite).

The Big Screen UI shows up when streaming and sound and input is transferred between host/client but the image is just black once a game is launched.

I worked around this by running Steam itself in gamescope using the -e flag: gamescope -W 1920 -H 1080 -w 3840 -h 2160 -r 60 -e --force-grab-cursor --grab --framerate-limit 60 -- steam -tenfoot

But this requires that I restart steam every time I want to stream games which I also worked around by setting up GSConnect with commands to restart Steam with gamescope so that I don't have to have physical access to my host to stream.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-3506866731

This is unfortunate this is happening, and it's good that you found a workaround for future readers. But as others have noted, when using the officially supported Operating System and Steam client + SteamLink which has been distributed directly by Valve, you needn't use a workaround such as this. For more information read my comment on https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-3506754084

But good work nonetheless, and all the best to your remote gaming endeavors!

While Ubuntu might be the official Linux distribution for Steam supported on PC; The Steam flatpak on FlatHub is NOT the officially supported package. The Flatpak is community maintained just like every other Linux distribution's package. The officially supported Steam package for Linux is: https://cdn.akamai.steamstatic.com/client/installer/steam.deb

While Ubuntu might be the official Linux distribution for Steam supported on PC; The Steam flatpak on FlatHub is NOT the officially supported package. The Flatpak is community maintained just like every other Linux distribution's package. The officially supported Steam package for Linux is: https://cdn.akamai.steamstatic.com/client/installer/steam.deb

Thank you for clearing that up, I've edited my previous comment to prevent any unnecessary confusion. As for anyone else reading this thread, the installer that @mwp-foss linked is what should be used for testing when opening bug reports (in an ideal world)

The Big Screen UI shows up when streaming and sound and input is transferred between host/client but the image is just black once a game is launched.

Yeah, I admit I had/have that issue too but only with one specific game for some reason, I never actually did much troubleshooting since Sunshine worked.

I worked around this by running Steam itself in gamescope using the -e flag: gamescope -W 1920 -H 1080 -w 3840 -h 2160 -r 60 -e --force-grab-cursor --grab --framerate-limit 60 -- steam -tenfoot

This isn't working for me under Fedora F43 with the Nvidia drivers -- I seem to be running into https://github.com/ValveSoftware/gamescope/issues/1596

If I start it natively, then the display works but never streams the game.

If I go through gamescope, then I can see the cursor on the screen and move it around with the controller, but no actual rendering from Steam, which makes it difficult to actually launch games.

Also having the Wayland Steam Link black screen issue as well. Surprised this is still going on.

Also, these repos aren't linked anywhere besides in search results, nor is the download for Steam Link itself easily findable on the Steam Link steam page. Really wish this stuff was cleaned up and unneeded repos were removed/archived or hidden.

Some observations:

• Hitting the "Steam Button" brings up an overlay on the host machine, but on the Steam Link client this is just a black screen
• If I go to the desktop, the client also sees a black screen except for the cursor
• Streaming DOES work to another copy of Steam via Remote Play
• This happens on both a Steam Link device and on a mobile phone running Steam Link

So there's something fundamentally different between Remote Play and Steam Link that makes the latter not work.

EDIT: I found a workaround. If I start Big Picture Mode on the host and switch it to windowed mode, then everything starts working (with the exception of streaming the desktop). If the host is running Big Picture Mode in a window, then launching games works fine.

FURTHER EDIT: It works for my phone if I start Big Picture Mode in windowed mode, however it still doesn't work on the Steam Link. To get the Steam Link to work, I have to first start a game using my phone, then connect to the running session from the Steam Link. I can then disconnect from the session on my phone. Additionally, the Steam host session stops working after I exit the game.

Issue for me too

Streaming from: ArchLinux w/ Gnome w/ wayland
Streaming to: Steam Link

Probably an issue if I try to stream to my steam deck too.
Haven't tried that since Gnome forced me to switch from X11 to Wayland...

What I see is a black screen whenever I launch a game from remote play...

I did a lot of troubleshooting on this issue, and for me, changing proton version to 9.0.4 for exclusively the troublesome game solved the issue for me.

Nothing else worked.

Although, The game couldn't find my save file anymore after doing that... but.. yea
Ticket w/ details: https://github.com/ValveSoftware/steam-for-linux/issues/12535

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-3567348636

I have noticed the black screen issue doesn't happen if you use the normal steam client, it goes back to what happened before, the side panel appears in the middle of the screen and everything else is black around it.

Atleast I can use it even tho it looks stupid lol.

The overlay also struggles on dirt rally 2.0 I have noticed often having to spam the overlay button to get it to appear.

Also having this issue. Fedora 41 and 42 hosting to Pixel 8, Lenovo Chromebook, and another Fedora Steam client.

I am having this issue with Arch Linux (2026.01.01) & KDE Plasma 6 to my Steam Link. The stream is highly delayed and low FPS while viewing the Steam client (Big Picture Mode) as well as my desktop. The sidemenu displays exactly like @pollux78 has posted above. However, when I launch a game, it seems to run fine (no lag or low fps), but the overlay doesn't work properly. I launch steam using the --pipewire switch according to the discussion in #5591

Hi.

I think I got relevant logs yesterday.

It occurred to me to check if Final Fantasy XIV Launcher worked and magically it did. It had been refusing to display the Vulkan capture and kept falling back to Black screen since I installed it. Unfortunately after yesterday's afternoon it broke again and in the evening it was back to black screen. This time, though I have logs:

steam-console-capture-active.txt
steam-console-capture-broken.txt

https://github.com/ValveSoftware/steam-for-linux/issues/12674

So it seems like it is something to do with Nvidia Encoder.

Software works but its locked to fullscreen.

Any suggestions?

Hello, I'm also facing this issue with Steam (Flatpak) + KDE 6 + NixOS Unstable (~26.11-pre) + Wayland + AMD GPU. Symtoms and what works for me. I'm testing with Dead Cells or the "connect" feature in the settings, the behaviour is identical:

• Launching without any modifications: Game stats on the remote node (game server), steam client starts connecting, game server gets a prompt to allow controlling inputs (keyboard+mouse)., the client can then issue inputs (like mouse movent) to the game server, but it does not show anything on the screen (black screen with only the cursor), I also get the audio through, just not video.

• Doing exaclty the same with the current Steam Beta, it behaves identically most of the time, but some times the client window gets stuck in the spinner / loading screen for the remote transmission.

• Using steam link, same as the first case, with the slight caveat that the Steam "big picture" does seem to be captured, ie, the library of games, etc I can browse and control just fine. But once I open a game it gets a black screen + cursor. Fiddling with Alt+Tab on the host between steam and the game shows that it is seemingly only capable of capturing itself, not the games it launches.

• Fiddling with enabling/disabling hardware encoding in steam settings, etc. No change.

• Using --pipewire (default client), it shows up the KDE pipewire screen selection prompt, and everything seems to work, steam is captured, the games I launch are captured, etc.

With this in mind, is there a reason that --pipewire is not the default through some kind of auto-configuration? Or do I have something busted on my system? Is there a way to instruct Steam to always use that option?

Since you're using KDE 6, you can edit your shortcut on the app launcher by pressing Super (aka Start), going to 'Games' on the left-hand side, right-click 'Steam' and click 'Edit Application...' and then adding -pipewire to the launch command.

anyone tried the flatpak version?

Arch Gnome + Wayland = same problem
Arch Gnome + Wayland + Flatpack steam = same problem
Arch Gnome + Wayland + steam (Native) = same problem

I think I sorta narrowed down the issue to wayland-based games (?). For example, the free game Altitude seems to run fine on Flatpak'd Steam (non-beta) + KDE Plasma 6 (Wayland) + No extra flags. Factorio doesn't, and I remembered that it had a switch for using Wayland or X11, on Wayland set in Factorio's settings I get a black video screen with only the cursor, but with the X11 set Factorio it works reliably. Note that I'm talking about the setting in the game, the system itself is still Wayland.

So I guess it is some bug in whatever logic is used to capture a wayland window/app in Steam. Anybody else can reproduce?

Have been trying to diagnose this issue on CachyOS with Wayland, although I think for a different usecase to what some of the discussion has been around. Alongside games I use the steam link to stream firefox and VLC to my TV to watch things, and Wayland does not let you do any sort of viewing of the screen when you minimise steam and leave big picture mode.

Without any changes mentioned by other commenters I get a black screen on the TV, with the mouse pointer only moving on the TV when it is hovering over the steam client - if it moves off the steam client the mouse pointer stops moving on the TV but continues to move about on the computer's monitors.

adding -pipewire to the launch command for steam managed to get the selected screen to be visible when out of big picture mode, but the mouse pointer position stays stationary on the TV the steam link is casting to (while moving about on the computer's monitors) when firefox or VLC is the top window in the hierarchy. It looks like -pipewire will capture the screen but not the mouse pointer movement unless the mouse pointer is directly over the steam client.

I do not get this issue with the steam link when on an X11 desktop session.

This issue has been tracked for 7 years, and we still don’t have a solution?

After switching to Linux, my Steam Link basically became useless. I really miss it. On top of that, I can’t even stream to my phone or Steam Deck anymore. Please give this problem some attention.

I have the same issue: black screen as soon as the game starts. Some games work if I start an X11 session, but even then things behave very strangely. For example, in Baldur’s Gate 3, playing in split screen makes the right side of the screen (player 2) run at something like 0.4 FPS or less, which makes it completely unusable.

This problem also affects other features like Remote Play Together AND Steam VR!!!. Steam really needs to properly support Wayland's screen capture methods. I mean, Sunshine and Moonlight works perfectly on the same hardware/software stack, just go and steal their code and paste it into steam or something!

I'm running Bazzite (Wayland), Mesa 26.0.1, on an RX 9070 XT.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-4014823361

At this point it'll be another 15 years if you take into account how long it takes them to do anything else.

Whatever you did today with the new pipewire screen prompt broke Final Fantasy VII via 7th Heaven. All I get is a black screen when the game is launched, but the actual mod manager displays just fine.

Maybe you could just keep the Sunshine/Moonlight talk somewhere else? People that are following this issue are following this issue to get updates on the status of Steam In-Home Streaming. I'm pretty sure that every single person that follows this Github issue already knows about Sunshine/Moonlight.

A PR that might fix this on nvidia: https://github.com/ValveSoftware/gamescope/pull/2094 Also submitted to Bazzite and might see it there faster

A PR that might fix this on nvidia: ValveSoftware/gamescope#2094 Also submitted to Bazzite and might see it there faster

I use Bazzite on my Deck.

Same on Fedora 43 KDE Wayland

Now that the new SteamOS Beta uses Wayland on KDE, Steam Link is basically broken on SteamOS too, making this an even bigger issu, its no longer just a Bazzite issue anymore.

This could allow Valve to come up with a solution sooner.

Can confirm this on my Steam Deck after upgrading the OS to Preview.

March 12th Build.
The issue doesn't occur while in Game Mode, as it streams my Steam Deck perfectly, but if I Switch to Desktop, it's a black screen, although you can still use it "normally".

Temporary workaround is to enable X11 Desktop Mode in the Developer Options until a solution is out.

Can confirm this on my Steam Deck after upgrading the OS to Preview.

March 12th Build. The issue doesn't occur while in Game Mode, as it streams my Steam Deck perfectly, but if I Switch to Desktop, it's a black screen, although you can still use it "normally".

Temporary workaround is to enable X11 Desktop Mode in the Developer Options until a solution is out.

This is due to the switch from X11 to Wayland in Desktop Mode. This has been open since 2019, so I'm not sure what's taking so long, and not a single dev has responded to anyone here on this.

Given the increasing adoption of Wayland and the obsolescence of X11, Valve will eventually be forced to address this issue. Especially since it actively supports and promotes gaming on Linux.

Given the increasing adoption of Wayland and the obsolescence of X11, Valve will eventually be forced to address this issue. Especially since it actively supports and promotes gaming on Linux.

Exactly, so why nothing's been fixed is what I'm wondering.

today's beta added these 2 error strings that get logged to streaming_log.txt

Steam does not have permission to capture the screen. You'll need to go to System Preferences, pick Privacy and Security, and go to Screen & System Audio Recording. Find Steam in the list of programs, and toggle the switch to the 'on' position.\n

Steam needs to be restarted with -pipewire as a parameter in order to be able to capture video. Be certain to select any monitors you wish to share and click 'Share' in the dialog that appears when Steam starts.\n

hopefully them recommending to enable pipewire will entice them to work on pipewire session restore support, bc having to select a given screen (or full workspace) on every start isn't a pleasant experience

Steam does not have permission to capture the screen. You'll need to go to System Preferences, pick Privacy and Security, and go to Screen & System Audio Recording. Find Steam in the list of programs, and toggle the switch to the 'on' position.

I'm on Kubuntu, does anyone know if there is an equivalent setting that I could use?

hopefully them recommending to enable pipewire will entice them to work on pipewire session restore support, bc having to select a given screen (or full workspace) on every start isn't a pleasant experience

Yeah I agree with you on that, and if that's done maybe they could only be "sharing the contents of your screen" or whatever only when you're actually using Steam Link or the like, cause otherwise you've eternally got a red dot in your status bar, and Do Not Disturb on by default.

@VoxelTek
KDE settings
System Settings → Application Permissions →Find Steam in list → Screen capture / Record screen→ Allow

@Jakewh That was the first place I looked, but the only options are Flatpak Permissions and Legacy X11 App Support, neither of which has what I want, considering I have the Debian package of Steam installed.

Agreed, I also do not have this option on Arch Linux, Plasma 6.6.4. Do you have a pre-release version of Plasma, or something?

Agreed, I also do not have this option on Arch Linux, Plasma 6.6.4. Do you have a pre-release version of Plasma, or something?

No. I have the latest version of Fedora 44, where the KDE version is 6.6.x

So someway somehow it started working without the pipewire flag, I gave Steam permission to capture my screen automatically and it just works now

@Jakewh That was the first place I looked, but the only options are Flatpak Permissions and Legacy X11 App Support, neither of which has what I want, considering I have the Debian package of Steam installed.

Try installing the kde-config-flatpak package.

@InceptionOfCode I think you're missing what I've said, I do have control over Flatpak apps, but I do not have Steam installed as a Flatpak app for several reasons.

@InceptionOfCode I think you're missing what I've said, I do have control over Flatpak apps, but I do not have Steam installed as a Flatpak app for several reasons.

Actually, I have to back them up on this one! I looked into it, and the KDE Control Module that manages Flatpak permissions, called Flatpak KCM, has scoped out to include all xdg-desktop-portal permissions!

You may have an earlier version of this KCM installed, or it's not detecting Steam for some reason.

Huh! My apologies, @InceptionOfCode. You're probably right @Orangestar12, my Application Permissions looks different to yours, so I'm guessing it's an older version.

apt says 6.4.5-0ubuntu1, so maybe I should try building and installing from source, if that's possible.

Decided to try out steam link again as there was a patch about improving this under a Wayland session and I now have to use -pipewire to get steam link to work properly or it won't capture the screen.

So far it was working fine, the cursor looks weird for some reason but when viewing the sidebar menu in big picture it appears as a single black green strip instead of the whole big picture with the sidebar appearing.

(RESOLVED✅)The desktop portal also keeps spawning every time you launch steam, i know the desktop portal can save with a token so that it doesn't re appear after re launching steam.

(RESOLVED❌)Another issue i have been met with is the virtual cursor it creates for you on the client isnt synced with the cursor position on the host machine, so when i move the cursor on my ayn odin 2 portal the cursor on the host isnt jumping to the right monitor and instead moving around where the cursor was left on the host machine like for example the right monitor instead of the middle monitor where it should be.

The cursor image that appears on the client device isn't exactly where the cursor is aswell, so when trying to click on let's say the rockstar launcher you can't see where the actual cursor is on the screen.

Also there is now heavy flickering on the ayn Odin 2 portal screen when looking at the big picture UI, this seems to be completely random if this flickering appears or not but i have been able to reproduce this issue 3 times now when connecting.

The other issue is with using wine Wayland, not only is there no steam input with the game but you can't interact with the steam big picture UI once the wine Wayland game is launched in fullscreen for example.

Video example below.

This is on latest steam beta client 1782344391, SteamRT3 enabled, cachyos, KDE Plasma 6.7.1, RX 6700 10GB.

I am using Video Beautiful, Audio Stereo, HEVC Vaapi, Hardware decoding, Low Latency Networking with everything else on automatic.

Although it's not explicitly mentioned, latest steam beta update finally fixes the session restore that didn't work, finally no more share portal that pops up on every start
https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/672871581268050197

Improved Pipewire session logic on Linux. If persistent capture permissions are granted to Steam, there will only be an active Pipewire session when streaming or recording.

(fixes the screen casting icon that was always there)

ive tested today after updating my steamdeck to SteamOS 3.8 and tried streaming from my linux pc with hyprland WM and it worked just fine :D

Was able to make steam client crash when toggling the steam big picture overlay in steam link on GTA IV, and was able to make steam client crash when trying to open my browser when in steam big picture and steam link.

This is on latest steam beta client 1782344391, SteamRT3 enabled, cachyos, KDE Plasma 6.7.1, RX 6700 10GB.

I am experiencing the same issues as stated before above aswell.

https://github.com/ValveSoftware/steam-for-linux/issues/6148#issuecomment-4632487985

steam link crash 1.zip
steam link crash 2.zip

Decided to try out the latest beta since people are reporting streaming improvements. This is using my old hardware Steam Link.

First, with no changes to any settings, Steam was able to start streaming just fine.

Streaming the desktop caused a black screen, but input was working and no popups interrupted me.

Most games had no problems streaming

But some games, like The Outlast Trials here, only showed part of the screen for some reason?

For reference, the title screen is supposed to look like this:

You can see the triangle on the game's logo poking out of the bottom right.

Running the game in gamescope not only broke streaming but broke Steam Input as well.

Next I booted Steam with steam -pipewire. I was met with a portal selection dialogue thing, which I couldn't help but notice Sunshine's KScreen implementation does not do. Instead, Sunshine gives me a notification that it "started remote desktop" (as opposed to capturing the screen). Attempting to start a stream streamed roughly a quarter of a second of video and then caused Steam to crash. It then rebooted itself, and the network performance got REALLY bad. Attempting to boot the problematic game had the same issue, but centered onscreen instead of in the top left.

All in all a mixed bag, but promising!

Chiming in to say that I finally got things working, with HW encoding & decoding working, with and without steam -pipewire flag.

My user-error was that I forgot that I put my steam deck on beta, while my desktop host machine was not on the beta. Once I switched my desktop to beta too, then it "just worked". Mixing beta and not beta was a silly mistake by me.

For reference:

• client: Steam Deck (LCD edition)
• host: Fedora 44, Steam installed with rpm/dnf, not via Flatpak

Along the way I did have to install the multimedia packages from RPM Fusion for the hardware encoding to work (ffmpeg was logging errors about that, as seen when opening steam using the command-line with either just steam or steam -pipewire), as I had forgotten to reinstall those after my latest machine wipe.