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.

[falk4243]

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?

[aqxa1]

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.

[caseif]

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.

[Willdrick]

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

[ErikReider]

~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

[iMonZ]

Any news here?

[Saroumane]

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 ?

[falk4243]

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?

[Meister1593]

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.

[Zoarial94]

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.

[MayeulC]

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 from the steam command line

``` "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 |  |

[DistantThunder]

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?

[m1m1k4tz]

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

[dudekaa]

@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

[Luxxii]

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.

[YellowOnion]

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.

[slagiewka]

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

[slagiewka]

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.

[MayeulC]

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

[falk4243]

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.

[Fatmice]

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

[m1m1k4tz]

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

[m1m1k4tz]

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

[dc740]

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.

[minikN]

Is there any new information regarding this since the introduction of the new -gamepadui mode? I noticed that with classic big picture mode, it wouldn't even start without setting SDL_VIDEODRIVER=x11, whereas the new mode would start with the env var set to wayland, albeit still buggy, however with streaming, I still noticed the same issues as before (tried with -pipewire -pipewire-dmabuf

The issues being I only see a static screen with -pipewire and a black screen (on my TV) without any additional params. People have reported it working with -pioewire, never worked for me though.

[OSCrustacean]

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.

[aaron-trout]

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

[noobmagnet]

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.

[dc740]

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)

[ulibte]

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.

[deltatux]

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.

[777Raim]

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

[kisak-valve]

Hello @777Raim, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

[777Raim]

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

[kisak-valve]

Thanks, looking at your system information, there's no usable 32 bit vaapi driver? ( https://gist.github.com/777Raim/8815db8bb2541ef7ea9e33b83df58a60#file-gistfile1-txt-L299-L304 ) ~streaming_client~ could be using 32 bit vaapi while vainfo is testing 64 bit vaapi. EDIT: streaming_client is wrong for the host side of Remote Play, but the intent is the same.

[777Raim]

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

[Havard-SL]

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

[noobmagnet]

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.

[slagiewka]

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.

[777Raim]

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

Have last beta + Android Steam Link

[aaron-trout]

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

[TheJackiMonster]

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.

[m1m1k4tz]

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

[slagiewka]

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.

[m1m1k4tz]

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

[bayazidbh]

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.

[perroboc]

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

[MayeulC]

@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/%22It-doesn't-work%22-Troubleshooting-Checklist

You can observe pipewire streams with helvum or qpwgraph.

[Saroumane]

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.

[Willdrick]

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?