OBS crashes with explicit sync on wayland

[mahkoh]

Operating System Info

Other

Other OS

Arch Linux

OBS Studio Version

30.1.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/WQGyYH2S1OMk7op4

OBS Studio Crash Log URL

No response

Expected Behavior

OBS does not crash.

Current Behavior

OBS crashes.

Steps to Reproduce

Start OBS under a wayland compositor that supports explicit sync and with graphics drivers that support explicit sync. With up-to-date nvidia drivers, that should always be the case. With mesa, you will also have to set the environment variable MESA_LOADER_DRIVER_OVERRIDE=zink to ensure that vulkan is being used under the hood.

After starting OBS, right click on the preview and select Windowed Projector (Preview). You might have to repeat this several times.

OBS crashes.

Anything else we should know?

I am reasonably certain that this is caused by the following series of events:

1. OBS creates a QT window.
2. OBS extracts the underlying wl_surface.
3. OBS uses that wl_surface to create an OpenGL context.
4. Later, QT tries to commit a SHM buffer to that wl_surface. Possibly due to a resize event. Since QT does not know anything about the OpenGL context, this crashes.

The last step is unsound. QT must not not manipulate the surface buffer while the surface is owned by an OpenGL or Vulkan context. I believe that that much is required by the OpenGL and Vulkan specifications.

The question is if QT is in the wrong here (although I don't see how, QT seems to know nothing about OBS creating on OpenGL context) or if this is an OBS bug because OBS creates an OpenGL context without properly informing QT about this.

@davidedmundson can you comment on the above?

[davidedmundson]

Without remembering any OBS code:

• if you're making a QWidget then doing myWidget->create / myWidget->winId to get a window that's an OBS bug, as you've got Qt and OBS drawing into the same thing

• if you're making a QWindow directly and Qt is suddenly attaching buffers, that's a Qt bug and I'll look into it further.

[kkartaltepe]

OBS draws directly into the QWidget for all displays (OBS rendered content), perhaps the project is using a different setting that causes the shm to be attached.

[Defarius]

I am also experiencing this issue or something similar. It seems to somewhat fix itself but it has reappeared today after installing openrazer.
2024-09-02 04-46-41.txt

[amshafer]

I posted a question about mixing app and GL buffer attaches on wayland that might be relevant here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/211

[kkartaltepe]

I'm pretty sure removing https://github.com/obsproject/obs-studio/blob/master/UI/window-projector.cpp#L41-L44 will resolve this for people experiencing issues. Unfortunately a real solution is a bit more complicated assuming this really does work.

[mahkoh]

I believe the problematic code also causes the following issue: When resizing a projector window, the window becomes transparent.

flicker.mp4

[iotku]

Can confirm this still occurs under the Flatpak version on KDE Plasma 6.2.0/QT Ver 6.7.2 / Nvidia 1080ti (driver 560.35.03).

When trying to open the windowed projector I get this:

warning: Creating a popup with a parent, QWidgetWindow(0x5586428673e0, name="OBSBasicWindow") which does not match the current topmost grabbing popup, QWidgetWindow(0x558644e94190, name="QMenuClassWindow") With some shell surface protocols, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly. Please fix the transient parent of the popup.
wp_linux_drm_syncobj_surface_v1@103: error 4: explicit sync is used, but no acquire point is set
warning: The Wayland connection experienced a fatal error: Protocol error

And then OBS crashes

[ochilan]

@kkartaltepe I tried building a Flatpak from master today with the "WA_PaintOnScreen" part removed as you suggested. At first sight, it works nicely for me under Wayland (KDE 6.2.1), including resizing the windowed projector smoothly. When running this modified version under X11, however, resizing the projector window freezes rendering in OBS until after I stop resizing the window, causing framedrops.

I don't know what possible other drawbacks there could be when running this modified version under Wayland, but if it works nicely, could it be a solution to conditionally set WA_PaintOnScreen if running under X11 only?

Edit: Here's a suggestion for conditionally setting the attribute: OchiLive@d2189ab - feel free to try it out and let me know if it may be worthwhile to make a pull request out of it. Maybe it should be tested in various desktop environments.

[mrdev023]

i get this error on OBS 31.0.1, any news about it ?

[thingi]

i get this error on OBS 31.0.1, any news about it ?

This is not an OBS issue, I get exactly the same problem using looking-glass.io, the fix (well workaround) is to add "__NV_DISABLE_EXPLICIT_SYNC=1" to your environment variables or downgrade egl-wayland to version 1.1.13 (but I don't recommend that).

[kkartaltepe]

Yes this is an obs issue and we have a tentative fix pending, however there are even more bugs and broken behavior in Qt with the "correct" qwidgets. So until we find suitable workarounds to avoid breaking more people you will have to workaround your nvidia situation.

[amshafer]

@kkartaltepe what other explicit sync related Qt issues are you referring to?

[kkartaltepe]

The remaining issues are unrelated to explicit sync, and just the regular wayland issues that qt and gnome cant agree on how the wayland protocol works, or just plain bugs in qt.

[davidedmundson]

If there are bugs in Qt + Wayland please do reach out to the QtWayland maintainer (me), I can help fix anything either here or upstream.

[kkartaltepe]

You are free to remove the workaround from #11773 and test the fullscreen/windowing functionality on gnome. Its unlikely I would ever have the time to try and craft a minimal reproducer for a Qt bug report, and its pretty low value since any fixes in qt wont be usable by downstreams like us for at least 2 years anyway due to distro and qt release processes.