In-home Streaming + Wayland

[Mushoz]

Your system information

• Steam client version (build number or date): February 18th build
• Distribution (e.g. Ubuntu): Arch 5.0.2 Kernel
• Opted into Steam client beta?: No
• Have you checked for system updates?: Yes, system is fully up-to-date

Please describe your issue in as much detail as possible:

Whenever I run my desktop with Wayland, and connect my steamlink to my Desktop, the screen on the TV will be rubbish with every color of the rainbow all over the screen. The screencapture of the desktop is clearly not going as planned. Actions still work fine, and I can navigate via the controller connected to the steamlink by simply watching what I am doing on my computer screen. Once I launch a game, the corrupted mess disappears and I can properly see the game being streamed to the steamlink.

Steps for reproducing this issue:

1. Use Wayland (I am using Gnome on Wayland in case that matters)
2. Start steam
3. Start steamlink
4. Connect to desktop

What happens: I see a corrupted mess on my TV

What should happen: I should be seeing steam big-picture mode, as my computer display is showing.

Workaround: Use gnome on Xorg.

[MayeulC]

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?

[ghost]

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

[tgunnoe]

Same issue on Sway

[PMaynard]

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

[sinedoOo]

Same issue on Fedora 32 + Gnome wayland

[PMaynard]

anyone tried the flatpak version?

[fuzunspm]

same issue on Arch Linux swaywm/wayland + iPad setup

[MayeulC]

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.

[yokem55]

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.

[MayeulC]

@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.

[awmath]

@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.

[maweki]

@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.

[maweki]

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.

[awmath]

@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.

[awmath]

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...

[maweki]

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?

[awmath]

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)

[Tzigamm]

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

[michaelnew]

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.

[minikN]

Is this being actively worked on by Valve?

[maweki]

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.

[cinerea0]

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

[kode54]

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

[Mushoz]

@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?

[minikN]

@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

[etcinit]

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.

[Willdrick]

  * 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..

[ljrk0]

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.

[major-mayer]

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.

[EuanFH]

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?

[4e554c4c]

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:

[caseif]

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.

[eaglesemanation]

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

3. 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.

[kode54]

@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.

[eaglesemanation]

@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

[kode54]

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.

[caseif]

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).

[Roboron3042]

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)

[Mushoz]

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.

[EuanFH]

People having problems with big picture crashing make sure steam is started with this environment variable "SDL_VIDEODRIVER=x11" most people will set this globally to "SDL_VIDEODRIVER=wayland" this will cause the big picture to crash.

Another issue if you are seeing a black screen on the client try setting the games resolution to the same resolution of the client. This solved all my black screen problems.

[Mushoz]

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.

[Mushoz]

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 :)

[gjpin]

@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.

[major-mayer]

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.

[vlcfaria]

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

[Saroumane]

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

[ljrk0]

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.

[gibsonjareds]

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.

[vatula]

@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.

[Saroumane]

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.