Custom browser dock window under Wayland is transparent
rmnvgr opened this issue · 49 comments
Operating System Info
Other
Other OS
Fedora 33
OBS Studio Version
Other
OBS Studio Version (Other)
OBS 4074e68-modified (Flatpak bundle of obsproject/obs-studio#4431)
OBS Studio Log URL
https://obsproject.com/logs/FJfJkTBIEjv7KI55
OBS Studio Crash Log URL
No response
Expected Behavior
The content of the window should be visible.
Current Behavior
The content of the window is transparent, only the border and titlebar is visible.
Steps to Reproduce
- Open OBS in a Wayland session
- Create a new custom browser dock (View → Docks → Custom browser docks)
Anything else we should know?
No response
Screenshot:
This should probably be disabled on wayland, the browser docks were not updated to work on wayland yet.
This should probably be disabled on wayland, the browser docks were not updated to work on wayland yet.
That sounds safest, if doable to avoid this subpar UX.
@GeorgesStavracas Just to clarify, what is needed to actually fix this? Changes on our side? Qt patches?
I'm not really sure. I suspect this problem exists because CEF is using Xwayland to render, and then passing the contents to a Wayland application. This just can't go well. But it can be something else entirely...
Hmm Browser Docks should be deactivated from what I remember when you run obs in wayland because of known issues.
Hmm Browser Docks should be deactivated from what I remember when you run obs in wayland because of known issues.
Yes, this was opened before we disabled them on Wayland. I was just asking for clarity on what would need to be done to actually fix the issue rather than temporarily disabling them, which we've already done.
I actually dont know how the browser sources work at all, but what I think is happening here is.
- CEF only runs with an X11 windowing backend (basically no one runs a wayland compositor that doesnt also provide X11 through Xwayland, but we can assume if they did disable Xwayland CEF just wouldnt load at all on that system).
- OBS sources without texture sharing will download the frames out of cef and load them into our graphics context so they work regardless of wayland/x11.
- OBS Panels try to share window handles, but since OBS has wayland handles and CEF expects X11 it fails and the wayland surface is transparent.
Hi every one,
may I suggest to improve the user experience of concerned user and adapt the current workaround (hiding under "Docks menu" the option "add Custom browser Docks")?
Well... I did not wait for the response of if I may suggest, or not. Therefore, if the response is no, please ignore the below lines.
My suggestion would be to leave the option in the menu. It opens a popup, explaining, it is not supported yet on Wayland, and the user should go back to x11/x.org from the loging screen, to be able to use this. At least, one quickly knows from the application itself, that its problem is known and there is a quickfix.
I lost a lot of time trying snap, flatpak, then deb, then older versions, (parallel to searches on duckduckgo), ... until someone pointed out the problem on discord.
Of course, if the solution is already on the pipe, please ignore this silly suggestion.
Of course also: You are all doing an amazing work and I thank you all for this!
Just spent an entire day trying to figure out why my build wasn't showing the custom docks option. logged in to X11 after seeing this bug and magically everything worked of course. sigh. Hope this gets fixed soon
One of my community members for Nobara accidentally stumbled upon a workaround for this while troubleshooting another issue. Launching OBS with QT_QPA_PLATFORM=xcb obs allows the docks and integrations to all work within wayland :o
That's on XWayland and can result in some other weird behaviour. If it works for them that's great but it is not supported. (and yes that's been known for a while ;) )
That's on XWayland and can result in some other weird behaviour. If it works for them that's great but it is not supported. (and yes that's been known for a while ;) )
yeah i noticed it breaks obs-vkcapture on nvidia (works fine on amd)
OK, I got it to work, and found other behavior that you might be interested in.
Operating System Info
Ubuntu 22.10
OBS Studio Version
Git
OBS Studio Log URL
https://obsproject.com/logs/4WXvjRYBshjkFrRA
Expected Behavior
Expected behavior would be to NOT work without the temporary commit that disable custom browser docks on wayland.
obsproject/obs-studio@c7aacea
Current Behavior
It DOES work, therefore the disabling of custom browser docks is useless.
If you build OBS with the commit reverted, and you start OBS without the flags, it works but browser-docks are disabled, so there's no difference with what we have now.
(commit has no impact, no crash or else)
If you start with the flags, it also add the browser-docks to the already working OBS setup on xwayland (with pipewire screen-capture and any wayland specific other features)
Steps to Reproduce
- Clone OBS-studio.
- Revert commit
7402271392a6a74fb49f16d84fb3c04c1b603d9ain obs-browser. - Build from source.
- Start OBS with qt (for X):
GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb obs. - Custom browser docks works while on wayland host.
Anything else we should know?
(I tested it on Arch and the last Ubuntu, they both worked)
This was mentioned by GE above and does not need the patch reverted.
And as stated above, if it works for you, good on you, that's your business. That doesn't make it a universal/acceptable solution though as you were told in obsproject/obs-studio#9369.
@mihawk90 that's odd because it didn't work before the revert. I tested this solution in 2 of my setups and it unlocked the situation in both of them. And even if it didn't worked, the reverted commit didn't make any difference unless obs was started with the flag aswell.
That's why I'm full of incomprehension here.
In one hand, it seems like the issue is not really a thing anymore (I don't think it works "just for me", but for every wayland users), and in the other hand, reverting the commit doesn't change a thing for 99.99% of the users and just provide fallbacks for the ones that are interested in the feature (I do understand however that it doesn't mean that you're going to support xwayland or anything, it's just a matter of not blocking options in the code if it has no other effects than preventing it to work in some cases).
Apologies for my previous (now deleted) comment in case you read it, it came off more rough then intended.
The title of the video is however slightly misleading as it is not Wayland that breaks this feature. It is a missing implementation on CEFs side, which yes only manifests on Wayland, however that is not Waylands fault.
Either way, for future reference: We're waiting on chromiumembedded/cef#2804
Specifically, see the comments from on Jan 31, 2022:
What’s currently missing (and covered by this issue) is the ability to embed CEF windows in third-party Wayland applications. That requires providing a Wayland alternative to the X11 code that is currently #ifdef-d out of the CEF Ozone build.
As I understand this comment there is currently no way for the OBS team to embed CEF "natively" into OBS on Wayland. XWayland via QT_QPA_PLATFORM (as mentioned above) works in some usecases, but it breaks others so it cannot be default behaviour.
edit: Matt also addressed this in a comment on the video.
Is there a reason we use CEF directly over QtWebengine? (other than the porting work)
The latter would be trivially embeddable, either as the widget or textures can be retrieved and used in any way.
Short answer is that QtWebengine doesn't offer us anything over the existing implementation, and is missing core functionality that we have patched in to CEF (OSR, hardware accel, shared textures, audio routing). It would be a lot of extra work to port it for reduced functionality. QtWebengine also tends to lag behind CEF proper.
Short answer is that QtWebengine doesn't offer us anything over the existing implementation, and is missing core functionality that we have patched in to CEF (OSR, hardware accel, shared textures, audio routing). It would be a lot of extra work to port it for reduced functionality. QtWebengine also tends to lag behind CEF proper.
What about now in 2024?
Is there any alternatives that fix this simple solution of no custom browser docks for Wayland? (Without using an external app.)
any news?
Fedora 41 will exclusively use Wayland. Is there any workaround available or has there been any progress on this? Thank you!
For now, the workaround is starting obs for X (or xwayland) with theses arguments :
GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb obs
For now, the workaround is starting obs for X (or xwayland) with theses arguments :
GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb obs
Thank you - will this make docks working on the Wayland?
For now, the workaround is starting obs for X (or xwayland) with theses arguments :
GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb obsThank you - will this make docks working on the Wayland?
It's forcing OBS to run under xwayland which will bring back the browser docks so yes it will work
any news?
We are still waiting on CEF.
Fedora 41 will exclusively use Wayland.
Not true. You can still install the X sessions manually.
the workaround is starting obs for X (or xwayland) with theses arguments
This is not supported as noted multiple times above. If it works for you, great, but if you run into issues, you're on your own.
That's on XWayland and can result in some other weird behaviour. If it works for them that's great but it is not supported. (and yes that's been known for a while ;) )
yeah i noticed it breaks obs-vkcapture on nvidia (works fine on amd)
Thanks! QT_QPA_PLATFORM=xcb worked like a charm on openSUSE Tumbleweed with Wayland + 7800 XT since August of this year - no issues AMD fans - Good Luck Green with your CEF waits 👍
The proposed fix doesn't seem to work on Arch+KDE:
$ GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb obs
debug: Found portal inhibitor
debug: Attempted path: /usr/bin/../share/obs/obs-studio/locale/en-US.ini
debug: Attempted path: /usr/bin/../share/obs/obs-studio/locale.ini
debug: Attempted path: /usr/bin/../share/obs/obs-studio/themes
debug: Attempted path: /usr/bin/../share/obs/obs-studio/themes/
warning: ReadOne on org.freedesktop.portal.Settings returned an invalid reply
info: Using EGL/X11
info: CPU Name: AMD Ryzen 9 7900X 12-Core Processor
info: CPU Speed: 5462.421MHz
info: Physical Cores: 12, Logical Cores: 24
info: Physical Memory: 63498MB Total, 39159MB Free
info: Kernel Version: Linux 6.12.4-zen1-1-zen
info: Distribution: "Arch Linux" Unknown
info: Desktop Environment: KDE (KDE)
info: Session Type: wayland
info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.24.1
info: Qt Version: 6.8.1 (runtime), 6.8.1 (compiled)
info: Portable mode: false
info: OBS 31.0.0-browser-3 (linux)
info: ---------------------------------
info: ---------------------------------
info: audio settings reset:
samples per sec: 48000
speakers: 2
max buffering: 960 milliseconds
buffering type: dynamically increasing
info: ---------------------------------
info: Initializing OpenGL...
[1] 82405 segmentation fault (core dumped) GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb obs
Under wayland OBS runs fine, but the option for a custom browser dock is missing.
The proposed fix doesn't seem to work on Arch+KDE:
$ GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb obs debug: Found portal inhibitor debug: Attempted path: /usr/bin/../share/obs/obs-studio/locale/en-US.ini debug: Attempted path: /usr/bin/../share/obs/obs-studio/locale.ini debug: Attempted path: /usr/bin/../share/obs/obs-studio/themes debug: Attempted path: /usr/bin/../share/obs/obs-studio/themes/ warning: ReadOne on org.freedesktop.portal.Settings returned an invalid reply info: Using EGL/X11 info: CPU Name: AMD Ryzen 9 7900X 12-Core Processor info: CPU Speed: 5462.421MHz info: Physical Cores: 12, Logical Cores: 24 info: Physical Memory: 63498MB Total, 39159MB Free info: Kernel Version: Linux 6.12.4-zen1-1-zen info: Distribution: "Arch Linux" Unknown info: Desktop Environment: KDE (KDE) info: Session Type: wayland info: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.24.1 info: Qt Version: 6.8.1 (runtime), 6.8.1 (compiled) info: Portable mode: false info: OBS 31.0.0-browser-3 (linux) info: --------------------------------- info: --------------------------------- info: audio settings reset: samples per sec: 48000 speakers: 2 max buffering: 960 milliseconds buffering type: dynamically increasing info: --------------------------------- info: Initializing OpenGL... [1] 82405 segmentation fault (core dumped) GDK_BACKEND=x11 QT_QPA_PLATFORM=xcb obsUnder wayland OBS runs fine, but the option for a custom browser dock is missing.
What package of obs are you using on arch?
obs-studio-browser, as the obs-studio package does not provide a browser source.
@Martmists-GH you have a browser with obs-studio-liberty
Identical crash using obs-studio-liberty
Can we please stop adding comments here that don't contribute anything?
Every time one of these pointless comments is added a bunch of people are getting a notification about nothing.
As noted multiple times before, using this environment variable is unsupported in the first place.
If it works for you, cool. If it doesn't, move on. It's not expected to work and it is not "a proposed fix".
In that case, what's the recommended way to fix this?
As also noted various times already, run an X11 session.
If that is not an option for you, open the pages in a real browser.
In that case, what's the recommended way to fix this?
I use the Flatpak version of OBS studio and it works everytime with browser docks, all I need to do is turn off the Wayland socket in flatseal and the browser docks work perfectly but you might need to add those environment variables in flatseal also for OBS, as if your on nvidia it seems to not work when you turn off the Wayland socket requiring you to do one of those variables based on the desktop environment you are using
I use the Flatpak version of OBS studio and it works everytime with browser docks, all I need to do is turn off the Wayland socket in flatseal and the browser docks work perfectly but you might need to add those environment variables in flatseal also for OBS, as if your on nvidia it seems to not work when you turn off the Wayland socket requiring you to do one of those variables based on the desktop environment you are using
That has the same effect as setting the mentioned environment variable to force using X11. So not a solution, just a hacky workaround that cannot be recommended due to all of the issues that this brings with it.
In that case, what's the recommended way to fix this?
Somebody has to implement this properly in OBS. Unless a software developer does this, there won't be a fix.
I use the Flatpak version of OBS studio and it works everytime with browser docks, all I need to do is turn off the Wayland socket in flatseal and the browser docks work perfectly but you might need to add those environment variables in flatseal also for OBS, as if your on nvidia it seems to not work when you turn off the Wayland socket requiring you to do one of those variables based on the desktop environment you are using
That has the same effect as setting the mentioned environment variable to force using X11. So not a solution, just a hacky workaround that cannot be recommended due to all of the issues that this brings with it.
In that case, what's the recommended way to fix this?
Somebody has to implement this properly in OBS. Unless a software developer does this, there won't be a fix.
Pretty sure the problem has to do with the chromium cef project needing to implement Wayland and the fact that OBS developers don't want to update their cef version too high yet as it would require a lot of work, so the only solution is x11 or that workaround, I have 2 systems one being AMD and other nvidia, both work fine with that workaround for me on KDE plasma with the Flatpak version of obs
Somebody has to implement this properly in OBS.
No, OBS is not the issue here.
As also noted before, this is on CEF. CEF does not currently provide the means to export to an external surface (such as the Qt docks) on Wayland.
OBS developers don't want to update their cef version
CEF has just been updated in the 31 release.
Somebody has to implement this properly in OBS.
No, OBS is not the issue here. As also noted before, this is on CEF. CEF does not currently provide the means to export to an external surface (such as the Qt docks) on Wayland.
OBS developers don't want to update their cef version
CEF has just been updated in the 31 release.
Yes they did, but its version 127 which came out in july of this year, that wont have the necessary patches for wayland
As far as I know there have been no advancements in that respect in the 4 versions since then.
And besides it was the most recent version when development for the 31 cycle began. In fact at the time it was still in the RC stage.
It was also the version that merged the patches provided by reitowo et al to make the update possible in the first place.
So saying that an update is not wanted is just flat out false.
As far as I know there have been no advancements in that respect in the 4 versions since then.
And besides it was the most recent version when development for the 31 cycle began. In fact at the time it was still in the RC stage.It was also the version that merged the patches provided by reitowo et al to make the update possible in the first place.
So saying that an update is not wanted is just flat out false.
I never said the update was not needed, I said the OBS developers don't want to update to the highest version of chromium because it requires too much work and time, and as you pointed out not worth it because of Wayland not being ready in the cef project
I said the OBS developers don't want to update to the highest version
Which as I just explained is a false statement.
I said the OBS developers don't want to update to the highest version
Which as I just explained is a false statement.
Is it on the highest version of cef right now?
I don't think you understand how development works, so there is no point in discussing this with you further.
I said the OBS developers don't want to update to the highest version
Which as I just explained is a false statement.
Is it on the highest version of cef right now?
I'll explain it: Projects have release cycles and many projects don't want to update major dependencies in the current release to prevent breakage. So the next major release of OBS is probably the earliest which could ship with a newer version of CEF.
I'm saying this from general experience, I don't actually know, how OBS's release process works in detail.
Projects have release cycles and many projects don't want to update major dependencies in the current release to prevent breakage.
While that is correct, that is also not the point.
My point was that there was nothing more up-to-date available when development began. It doesn't get any more up-do-date then a current development version (and supplying patches to it).
Unless you have a timemachine in the basement I don't see how CEF could have been more up to date.
And on that note, newer CEF builds have already been tested, so the notion of not wanting to update seems far fetched at best.
If one doesn't have an understanding of how development works that is completely fine. But making accusations of what Devs do or don't want and then furthering said accusation with "is it...?" seems rude to me.
Projects have release cycles and many projects don't want to update major dependencies in the current release to prevent breakage.
While that is correct, that is also not the point.
My point was that there was nothing more up-to-date available when development began. It doesn't get any more up do date then a current development version.
Unless you have a timemachine in the basement I don't see how CEF could have been more up to date.
And on that note, newer CEF builds have already been tested, so the notion of not wanting to update seems far fetched at best.
If one doesn't have an understanding of how development works that is completely fine. But making accusations of what Devs do or don't want and then furthering said accusation with "is it...?" seems rude to me.
And i said it would require too much work and time to update to the newest version if they wanted too, i was never being "rude" i understand that when development starts you cant just jump ship to a newer version while everyone is working on that release, they can test newer cef versions all they like but that doesnt mean there wont be bugs and issues they will need to fix, which would require so much work and effort as i know obs has a lot of patches added onto cef that arent in the master branch of cef itself and so would have problems
Me saying is it on the newer version is asking you not obs devs as the newst version of cef is 131 not 127.
I dont know why you are denying everything im saying, saying im rude is quite funny.
I'm done with this conversation. Thanks :)
i know obs has a lot of patches added onto cef that arent in the master branch of cef
It actually doesn't anymore, that was most of the work that was done by reitowo et al.
Me saying is it on the newer version is asking you not obs devs as the newst version of cef is 131 not 127.
Then let me ask you how could it be on 131 when it wasn't even released at the time? Not even 128 was out at the time. How exactly do you think would that work?
But to answer your question "is it...?":
"Obviously not." (reason: see above)
As mentioned several times, this is an upstream issue. We're actively monitoring CEF updates, and we update as soon as we can.
And as has been explained several times already, but in summary again, updating CEF versions isn't just "increase the version number".
I'm going to close this as it's no real value to the project or anyone else to argue about how development cycles work. Thanks for the input, it's well heard.