Arch Linux

Can you elaborate? What happens exactly when you launch obs-studio? And what does the Qt bug you linked have to do with it?

Of course, this error pops up:

-----
$ obs
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

Aborted (core dumped)
-----

Now, with qt5-wayland installed, it launches as expected.

And did you set QT_QPA_PLATFORM=wayland?

Nevermind, I see OBS tries to outsmart Qt and sets the variable itself

https://github.com/obsproject/obs-studio/blob/master/UI/obs-app.cpp#L2024

I would like to mention that obs-studio would benefit from including xdg-desktop-portal as optional dependency as well, for pipewire display/window capture support on Wayland

As per https://github.com/obsproject/obs-studio/issues/5676

To clarify, you are proposing both qt5-wayland and xdg-desktop-portal are added as opt depends for wayland support? I'm not entirely convinced these are obs dependencies, and not dependencies of your desktop environment. But please share your thoughts and I'll seriously consider.

Is it possible to run Qt(5) apps on native Wayland without qt5-wayland?

What desktop environment allows screen capture via pipewire without xdg-desktop-portal?

https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_sharing

I would probably hesitate to include qt5-wayland as a dependency on the package, because otherwise you'd need to add it to -every- Qt app and that's kind of a lot. It should be the application's responsibility to gracefully fall back to x11 when qt5-wayland is not present, and the user can do their research on Wayland support to enable native Wayland for Qt apps if they need to.

xdg-desktop-portal is kind of a hard requirement for using any pipewire capture functionality though, regardless of desktop environment. Note that this may benefit x11 as well, because you can set OBS_USE_EGL=1 to use pipewire input sources under x11.

Yes I agree I'm not convinced. Then probably best to argue xdg-desktop-portal should be a dependency of pipewire?

You know what, that would be a better idea, yes.

I agree would be nice to have qt5-wayland and xdg-desktop-portal as optional dependencies. Seems a bit strange to have to install QT5 components "as explicit" when really the application has a hard requirement on it under any Wayland desktop environment. At least with an optional dependency it will allow the packages to be installed without having them removed automatically by house keeping.

.. and yes in my opinion it would make perfect sense for all QT5 apps that can run on Wayland to optionally depend on qt5-wayland in the same way I would expect all QT5 apps to depend on QT5.

I cannot make any strong argument for xdg-desktop-portal being opt depends for pipewire or apps that want to screen capture.

There is no hard requirement on qt5-wayland because it can and should be expected to default to XWayland when qt5-wayland is not present.

For what it's worth, qt5-wayland and qt6-wayland are already optional dependencies to qt5-base and qt6-base, respectively.

```
For what it's worth, qt5-wayland and qt6-wayland are already optional dependencies to qt5-base and qt6-base, respectively.
```

In that case, fair enough. I should have checked that first

@Ammako > it can and should be expected to default to XWayland when qt5-wayland is not present

That's what one should expect, yes, but as I said above obs-studio tries to outsmart Qt platform detection and enforces using the wayland platform when in a wayland session, even if it is not available.

Yes, but what I'm saying is that upstream issues are an upstream responsibility, not an Arch responsibility. The bug should be reported upstream, if it hasn't been yet.

If upstream refuses to fix it, it's better to patch than to hide the bug with an additional dependency, imo.