Hello @Newbytee, this looks like an intended change per Enabled pipewire desktop capture by default on Linux, pass -nopipewire on the command line to disable it in the 2021-09-23 Steam client beta update.
I would be very surprised if this is intentional. Generally, applications that use PipeWire should ask when they need it, not right on startup. Users should understand why they are sharing their screen, and there is no clear indication why my screen is being shared here.
I am experiencing the same issue on Arch KDE wayland session. The dialog shows up each time Steam starts. This definitely is not right.
I can confirm this as well. Pipewire should not be asking for this information on launch, rather when it is being called. I have all remote play, broadcasting, etc disabled in the client and it's still asking for this information on launch.
WIP bug report: If I accept the share screen request, any games that uses Proton will not show their window at all. I haven't tested this with Linux native games. If I didn't accept the request, the games runs normally
EDIT: I cannot reproduce this anymore, seems like everything works normally
I would be very surprised if this is intentional. Generally, applications that use PipeWire should ask when they need it, not right on startup. Users should understand why they are sharing their screen, and there is no clear indication why my screen is being shared here.
I can see why they are doing it though, when you are starting a game through remote play you tend to be not in front of the desktop to accept screen sharing request.
I can see why they are doing it though, when you are starting a game through remote play you tend to be not in front of the desktop to accept screen sharing request.
I'm pretty sure that's the reasoning for doing it this way, rather than each time Remote Play streaming is initiated. Part of the design of Remote Play is that it's initiated by the thin client (phone, laptop, Steam Link, smart-TV) rather than by the "big" gaming PC where the actual game runs, which might be in a different room.
See also https://github.com/flatpak/xdg-desktop-portal/issues/324: it's not currently possible to say "yes, share the screen, and always allow this in future", or programmatically set up permission non-interactively.
See also https://github.com/flatpak/xdg-desktop-portal/issues/523: it's not currently possible for Steam to say "I want to capture the whole screen, don't ask the user whether to share individual windows or the whole screen".
Perhaps the least-bad UX available, given what's currently possible, would be something like this:
The least that should be changed is that it shouldn't even ask for permission, if I have Remote Play completely disabled in the settings. I consider that happening nonetheless a bug.
Not sure if steam can choose the screen on it's own (maybe always the primary display), but that would be very helpful.
I'm not sure which monitor is which:

Something like this would be better:

From https://github.com/flatpak/xdg-desktop-portal/issues/324 it seems that @smcv don't want to duplicate the desktop specific code to access Pipewire, and in Flatpak this isn't possible at all. But it shows a UI problem in the portal chooser
@avoonix That UI is not part of Steam but rather xdg-desktop-portal-gtk, The behavior you're describing is something I've also really wanted and that ticket is at flatpak/xdg-desktop-portal-gtk#333.
There is a problem, but maybe this is more of a KDE problem not Steam problem. Or maybe this is portal problem. If I accepted the screen share prompt, KDE notification center automatically switches to do not disturb mode:

If I accept the screen share prompt for remote play to work, I lose my notifications unless I manually uncheck the do not disturb mode after accepting the prompt.
Will using RemoteDesktop in combination with ScreenCast fix this?
Hello @minecraft2048, that sounds like something to ask the KDE devs about. Most likely an unrelated issue.
I would guess this is a "feature" since it thinks when you share your screen you're probably presenting or such.
Hello, per "Pipewire desktop capture is disabled by default on Linux, launch Steam with the -pipewire command line option to enable" in the 2021-09-28 Steam client beta update, this issue should now be resolved. As the release note suggests, you now need to opt-in to the pipewire integration if you want to experiment with using Steam's Remote Play from a wayland-based desktop session.
I would guess this is a "feature" since it thinks when you share your screen you're probably presenting or such.
I think the whole user experience around the portal wasn't designed with use cases in mind like steam has 😐
Perhaps using https://github.com/flatpak/xdg-desktop-portal/pull/638 once it is merged might be a better solution in long run.
Update on 2022:
Ubuntu/fedora have wayland by default.
Broken scenario:
You start remote play from the couch. is: Steam Link starts a new session and/or uses wake-on-lan to turn on the PC and start Steam.
Steam doesn't even ask to share the screen.
Steam Link sees a black screen unless you physically go to the PC, restart steam with -pipewire argument, and manually share the screen.
I don't think this bug should be closed.
Hello @dc740, you're looking for the issue being tracked at #6148 instead of this issue report.
ah, that's correct. Thank you @kisak-valve
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
Right on startup of Steam, without initiating a remote play session or such, Steam causes this popup to appear:
Steps for reproducing this issue: