-
-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xdg-desktop-portal-wlr capture sources (screen/window) can only ever be one and the same source #4815
Comments
Provide a log from obs. |
'A' log or one that contains something specific/with a custom log setting or something? Because they show absolutely nothing in relation to the described behaviour at all. For the removal even less.
Log for the described reproduction steps; added 1 for display A, 2 for display B (both show display B at that point), then removed 2 (1 switches back to A) then 1. |
Just like the template specifies, a full log from when you experienced the issue. Please do not trim the log and provide it as is unaltered. |
Template didn't specify and only talked about a URL which I don't have? I assume if the application crashes it allows you to upload something or w/e but it's not crashing or anything. Just pulled this from
EDIT:
Full/complete OBS run of clean project; run OBS -> replication steps -> shutdown |
It seems to me that it's an issue in wlroots. On OBS side, each capture source spawns one separate thread and PipeWire loop, and they basically don't interact with each other. This seems like the internal state of xdg-desktop-portal-wlr gets confused with two streams. |
That sounds like it could be plausible. I did not find anything about such a limitation but that doesn't eliminate the possibility it isn't an upstream bug. The side-note/additional thing I mentioned in the "Anything else" segment (about the Window Capture == Screen Capture) is indeed xdg-desktop-portal-wlr related. Looks like that isn't supported yet and there is an open item for it emersion/xdg-desktop-portal-wlr#107 |
We cannot do anything on OBS side to work around this missing implementation, but it made me realize showing the window capture there is wrong and fixable. Incoming PR soon. |
Right now we just assume that every compositor and portal implementation exposes both window and monitor captures, but that's not true, and in fact the Desktop portal provides a simple mechanism to check which source types are available: a D-Bus property called "AvailableSourceTypes". Read this D-Bus property, and use it to conditionally register the desktop and the window captures. Related: obsproject#4815
@Omar007 would you please test the pull request above, and let us know if the "Window Capture (PipeWire)" entry is still visible on your machine? |
Right now we just assume that every compositor and portal implementation exposes both window and monitor captures, but that's not true, and in fact the Desktop portal provides a simple mechanism to check which source types are available: a D-Bus property called "AvailableSourceTypes". Read this D-Bus property, and use it to conditionally register the desktop and the window captures. Related: obsproject#4815
@GeorgesStavracas Sure, I can probably do so later today 👍 |
Looks like that works and hides the unsupported capture mode. Windows Capture (second to last item) is not shown in the "After" 👍 On the subject of OBS related improvements, as another unrelated side-note, I also noticed on start the screen for Screen Capture needed to be reselected every time OBS was started with one of those in a scene. Putting the side-notes aside for a bit and going back to the main/OG issue, I haven't gotten around to verifying the main issue outside of OBS yet so I can't confirm or deny whether or not the suspicion is correct. I should be able to do so this week. If it ends up being replicable outside of OBS I'll close this as an upstream issue. |
That is a limitation of the xdg-desktop-portal protocol. |
Ah alright, fair enough. I thought I read it can be done without a chooser (requiring the user to supply it directly which I figured could be done as a property/setting on the OBS Scene Capture component) but maybe that was something specifically for xdg-desktop-portal-wlr 🤷♂️ EDIT: yea it was indeed. Specific config file for xdg-desktop-portal-wlr; https://github.com/emersion/xdg-desktop-portal-wlr/blob/master/xdg-desktop-portal-wlr.5.scd |
Alright I was able to do a test of the OG problem using both OBS and Firefox. Using OBS to select 1 screen, then running Firefox with a screenshare using https://mozilla.github.io/webrtc-landing/gum_test.html and selecting another, it's showing the same behaviour crossing program borders as well so it's def. an xdg-desktop-portal-wlr issue. Thanks for all the info (and the tangent improvement on OBS 😁 ). Closing this for being an upstream problem 👍 |
Right now we just assume that every compositor and portal implementation exposes both window and monitor captures, but that's not true, and in fact the Desktop portal provides a simple mechanism to check which source types are available: a D-Bus property called "AvailableSourceTypes". Read this D-Bus property, and use it to conditionally register the desktop and the window captures. Related: #4815
Right now we just assume that every compositor and portal implementation exposes both window and monitor captures, but that's not true, and in fact the Desktop portal provides a simple mechanism to check which source types are available: a D-Bus property called "AvailableSourceTypes". Read this D-Bus property, and use it to conditionally register the desktop and the window captures. Related: obsproject#4815
Operating System Info
Other
Other OS
Arch Linux
OBS Studio Version
27.0.0
OBS Studio Version (Other)
No response
OBS Studio Log URL
N/A
OBS Studio Crash Log URL
No response
Expected Behavior
Each individual (new) Pipewire capture element to be isolated/unique in its configuration; each new Screen Capture can be a different screen and each new Window Capture can be a different window without affecting existing elements.
Current Behavior
After adding a new Pipewire capture element and selecting a different screen or window from the previously existing Pipewire capture elements, the old/existing ones are also changed to the new selection.
Steps to Reproduce
Anything else we should know?
It's not just limited only to the one previously added element, you can continue adding for as long as you want; all existing ones will change to the new selection.
When you remove the most recently added capture element, the previous ones will switch back to the screen you selected before it. You can also keep doing this for as long as you want.
So if you have 3 screens (A, B, C) and add a unique/new capture element for each, first you have 1 with A, then 1+2 with B, then 1+2+3 with C at the end. Removing in the order 3, 2, 1 results in the reverse. Removing in the order 1, 2, 3 only ever keeps C showing, removing in the order 3, 1, 2 (or 1, 3, 2) makes it end with B (the selection for 2) never showing A again.
Aside from the above behaviour, it also looks like the Window Capture element is (doing) the same as the Screen Capture (both capture screen/output) but that looks to me to be a different issue, most likely not even an OBS issue.
Probably a problem with XDG Desktop Portal wlr and/or the selection tool being used (slurp) as both elements result in the same selection command execution (
slurp -f %o -or
) and thus returned data; the output/screen name).Running Sway (wlroots based Wayland).
The text was updated successfully, but these errors were encountered: