Wayland in Fedora 31 does not allow focus grabbing from the compositer

[hobbes1069]

A user reports the following error when trying to launch MythTV frontend on Fedora 31 Beta:

qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

Per this forum thread it looks like it's no longer supported:

​https://forum.qt.io/topic/90639/comparing-qt-widgets-app-under-gnome-wayland-using-platform-wayland-egl-to-xcb/9

[Gary Buhrmaster]

In *theory* fixed with later Qt and later xdg-shell (I think Qt 5.12 (possibly backported to Qt 5.11) and weston 6). However, F31 beta's may be problematic in other ways. Is it reproducable on F30 stable?

[jayjaytay]

I can confirm that I'm getting the same error under Wayland and Fedora 31 final with the following packages installed:

qt5-qtwayland-5.12.5-2.fc31.x86_64
mutter-3.34.1-4.fc31.x86_64
weston-7.0.0-2.fc31.x86_64

MythTV works fine under Xorg, however.

[Stuart Auchterlonie]

Mark,

is this something we can take care of in your OpenGL rewrite, or do we need to address this separately?

Regards Stuart

[Stuart Auchterlonie]

Also crashes, see #13498

[Mark Kendall]

From the description, I'm not sure what the actual reported issue is here.

For me, in limited testing using master, mythfrontend starts as normal but the contents of the screen are not displayed. If I navigate as normal (by guesswork) to a playback screen, playback is fine and the UI is then displayed normally after exiting playback.

So the 'qt.qpa.wayland: Wayland does not support QWindow::requestActivate()' message *may* be a red herring - but somewhere we are triggering the correct behaviour when either entering or exiting playback.

If I force the use of the Qt painter, everything is fine (but no video playback)

[Mark Kendall]

Oops - forgot to reference this in commit.

Should be fixed by:

​https://github.com/MythTV/mythtv/commit/f42ae424cd54d356b6aa93625e83dcde99129a8f

[Mark Kendall]

Rendering works without issue on Wayland with master/v31 - although the requestActivate warnings are still received - they do not appear to be an issue.

Note: the fix applied to master/v31 cannot be backported as the code has changed too much - and a similar fix is unlikely to work with the old code regardless.

If there is still an issue, please open a new ticket.

[Mark Kendall]

At least 2 reports that this is still an issue.

[knutsondc]

Mark,

I've added my mythfrontend logfile to the list of attachments. Let me know if you want/need anything else from me. Thanks!

Darron

[panzerfather]

I can confirm that the GUI problem reported in comment:5:ticket:13483 also affects mythfrontend on Fedora 32. But on F32 no theme painter workaround (OpenGL, VAAPI or QT) is functionable to show the GUI. Video-Playback is functional and also the GUI is visible while a video is playing (e.g. when pausing it). But after you go back, only a black window is painted again.

So you have to use XOrg for a fully functional mythfrontend right now.

[Klaas de Waal]

I have done a clean install of Fedora 32 on my laptop. I have compiled today's master on this machine. The problem is that both mythtv-setup and mythfrontend do not show anything on the screen and both do freeze the GUI while waiting forever for input until killed fro a terminal outside the GUI.

The Fedora install is completely default/out-of-the-box.

This can probably be fixed by changing from the default Wayland to X11 but I would like MythTV to run on a default Fedora 32 installation, just like VLC. What is the way forward to achieve this?

I can help with debugging but I am not really familiar with this part of the code.

[Klaas de Waal]

A workaround, found in ​https://doc.qt.io/qt-5/wayland-and-qt.html, is to start the application with the -platform xcb option, as in:

mythtv-setup -platform xcb
mythfrontend -platform xcb

This does actually work, both for the GUI and for video playback. However, as I understand it, this should not be necessary, because the documentation says:

Qt clients can run on any Wayland compositor, including Weston, the reference compositor developed as part of the Wayland project.

The default desktop in Fedora 32 is Gnome and that uses another compositor.

When starting the Weston compositor in a separate session, after creating a configuration file that specifies X11 support:

[klaas@MyZen mythtv-master]$ cat  ~/.config/weston.ini
[core]
modules=xwayland.so

then mythtv-setup starts OK.

If a Qt5 application should be able to run on Wayland directly without the X11 layer then we should figure out which Qt widgets, or which use of the Qt widgets, does cause the problems.

If the statement "Qt clients can run on any Wayland compositor" does implicate "with the X11 layer" then the "-platform xcb" option can maybe built into mythtv as default.

[Gary Buhrmaster]

You may wish to try something like

QT_WAYLAND_SHELL_INTEGRATION=wl-shell mythtv-setup

If that works (well, the windows opens), that indicates you are likely experiencing one of the various Qt5/qt5wayland/compositor issues that have been floating around for some time (I have lost track of them all, and they tend to be hidden inside various bug reports regarding fullscreen or wayland or xdg-shell v6, etc.).

[Gary Buhrmaster]

Oh, and while you likely have it installed, I think for Fedora you need to make sure that the qt5-qtwayland package is installed which provides the integration (every distro names the various packages slightly differently).

[Klaas de Waal]

The qt5-qtwayland package is installed. Probably done by ansible as part of the "build from source" steps.

Starting mythtv-setup like this:

QT_WAYLAND_SHELL_INTEGRATION=wl-shell mythtv-setup

does work but the graphics is not correct; the underlying terminal window is visible through the unselected menu items. Picture is attached.

Starting mythtv-setup like this:

mythtv-setup -platform xcb

does work with correct graphics.

[Klaas de Waal]

Transparency in non-selected menu items when started with "QT_WAYLAND_SHELL_INTEGRATION=wl-shell mythtv- setup"

[Gary Buhrmaster]

I suspect the transparency is a MythTV issue with compositors, as the theme you are using specifies an alpha transparency which gets passed to the parent. I am not a Qt UI expert, but I suspect that MythTV needs to use something like autoFillBackground, or one of the myriad of other Qt attributes for a widget.

In my copious free time (i.e. don't expect anything soon-ish) I might try a few quick things, but I really don't do UIs (I am a cli person).

[Mark Kendall]

re transparency:-

​https://github.com/MythTV/mythtv/commit/9affd3aa74d251fca1d0e06a5c1875fd866cfde9#diff-ce45e1c524369d8ab31df7b89c2b74af

may help. If someone can test and confirm, I can backport that at least.

Otherwise, I can't test wayland until a new drive arrives and I've rebuilt my main dev machine.

[Gary Buhrmaster]

Replying to Mark Kendall:

If someone can test and confirm, I can backport that at least.

In my simple test case (run mythtv-setup on wayland) it does not seem to help (one can still see the underlying screen content as shown previously).

[Klaas de Waal]

Tested just now with the latest master but there are no changes. Summary of current behavior on Fedora 32/Wayland:

Just typing mythtv-setup results in the following messages

2020-07-27 22:38:51.639281 I  Qt: Wayland does not support QWindow::requestActivate()
2020-07-27 22:38:51.889890 I  Qt: Wayland does not support QWindow::requestActivate()

and then there is never a window.

When starting mythtv-setup like this

QT_WAYLAND_SHELL_INTEGRATION=wl-shell mythtv-setup

then the messages from "Qt: Wayland" do NOT appear and it works OK but there are the transparent windows.

When starting mythtv-setup like this

mythtv-setup -platform xcb

then it works OK.

[ggervasio]

(I think I got this from the forum.) This also works to make the GUI visible for me (Fedora 32):

QT_WAYLAND_DISABLE_WINDOWDECORATION=1 

[Stuart Auchterlonie]

Just ran a quick test with no extra environment variables or arguments. First thing that pops up in the logs that I find curious is

"Display: Requesting EGL for 'Mesa Project, 1.4'"

I thought desktop versions under wayland were meant to use OpenGL not OpenGLES ?

CoreContext opengl/mythrenderopengl.cpp:419:DebugFeatures  OpenGL: OpenGL vendor        : VMware, Inc.
CoreContext opengl/mythrenderopengl.cpp:420:DebugFeatures  OpenGL: OpenGL renderer      : llvmpipe (LLVM 10.0.0, 256 bits)
CoreContext opengl/mythrenderopengl.cpp:421:DebugFeatures  OpenGL: OpenGL version       : 3.1 Mesa 20.1.4
CoreContext opengl/mythrenderopengl.cpp:422:DebugFeatures  OpenGL: Qt platform          : wayland
CoreContext opengl/mythrenderopengl.cpp:425:DebugFeatures  OpenGL: EGL display          : Yes
CoreContext opengl/mythrenderopengl.cpp:426:DebugFeatures  OpenGL: EGL images           : Yes
CoreContext opengl/mythrenderopengl.cpp:428:DebugFeatures  OpenGL: Qt OpenGL format     : OpenGL 3.1
CoreContext opengl/mythrenderopengl.cpp:429:DebugFeatures  OpenGL: Qt OpenGL surface    : RGBA: 8888 Depth: 0 Stencil: 0
CoreContext opengl/mythrenderopengl.cpp:430:DebugFeatures  OpenGL: Max texture size     : 8192
CoreContext opengl/mythrenderopengl.cpp:431:DebugFeatures  OpenGL: Max texture units    : 192
CoreContext opengl/mythrenderopengl.cpp:432:DebugFeatures  OpenGL: Shaders              : Yes
CoreContext opengl/mythrenderopengl.cpp:433:DebugFeatures  OpenGL: NPOT textures        : Yes
CoreContext opengl/mythrenderopengl.cpp:434:DebugFeatures  OpenGL: Multitexturing       : Yes
CoreContext opengl/mythrenderopengl.cpp:435:DebugFeatures  OpenGL: Rectangular textures : Yes
CoreContext opengl/mythrenderopengl.cpp:437:DebugFeatures  OpenGL: Buffer mapping       : Yes
CoreContext opengl/mythrenderopengl.cpp:438:DebugFeatures  OpenGL: Framebuffer objects  : Yes
CoreContext opengl/mythrenderopengl.cpp:439:DebugFeatures  OpenGL: 16bit framebuffers   : Yes
CoreContext opengl/mythrenderopengl.cpp:440:DebugFeatures  OpenGL: Unpack Subimage      : Yes
CoreContext opengl/mythrenderopengl.cpp:441:DebugFeatures  OpenGL: GL_RED/GL_R8         : Yes

[David Hampton]

I see the same message on one of my Fedora32 frontends, running master from last night.

"Display: Requesting EGL for 'Mesa Project, 1.5'"

This is on an Intel NUC.

[David Hampton]

I should add that I'm running X not Wayland.

[Klaas de Waal]

Compiled the latest master just now and looks OK. Can now start mythtv-setup without additional environment variables or command line parameters and the main windows appears.

The following messages

2020-07-30 00:04:38.192053 I  Qt: Wayland does not support QWindow::requestActivate()
2020-07-30 00:04:38.345798 I  Qt: Wayland does not support QWindow::requestActivate()

do still appear. When an environment variable is set, either QT_WAYLAND_DISABLE_WINDOWDECORATION or QT_WAYLAND_SHELL_INTEGRATION these messages do not appear. In all cases I do now get the main window.

[Mark Kendall]

Not sure if I messed up the commit hook or it just hasn't processed yet - but this should be fixed in master following:-

​https://github.com/MythTV/mythtv/commit/b6e7e18a4c209a0dd246c4624db918af0d5152ff

Unless anyone still has isses, I will backport to fixes/31 in the next day or so.

As noted in the commit, there is probably a more performant fix for this issue - but it requires including Qt private headers.

p.s. re "Display: Requesting EGL for 'Mesa Project, 1.5'" - this is just some logging to show whether we are trying to force EGL over GLX - which is best for pretty much anything other than NVidia on linux. Wayland will be defaulting to egl anyway.

[Mark Kendall <mark.kendall@…>]

In b6e7e18a4c/mythtv:

Wayland: Fix alpha blending

• each window in wayland has its own buffer/texture and these are always

composited with alpha blending

• as a result any alpha blended areas of our UI will allow the

underlying window to be visible if the window/surface buffer has a
buffer with alpha

• usually the default surface format does not request a buffer with

alpha but when wayland decorations are enabled, Qt overrides the alpha
depth

• so as a workaround, disable Qt wayland decorations, which we don't

need anyway

• note - this may not be the best solution. Using

wl_surface_set_opaque_region on our surface would allow the compositor
to optimise rendering as it knows it does not need to show anything
hidden by the window. In testing this works but requires linking to
libwayland-client and including Qt private headers (which is far from
ideal)

• refs #13483

[Mark Kendall <mark.kendall@…>]

In e537ea801/mythtv:

Wayland: Fix alpha blending

• each window in wayland has its own buffer/texture and these are always

composited with alpha blending

• as a result any alpha blended areas of our UI will allow the

underlying window to be visible if the window/surface buffer has a
buffer with alpha

• usually the default surface format does not request a buffer with

alpha but when wayland decorations are enabled, Qt overrides the alpha
depth

• so as a workaround, disable Qt wayland decorations, which we don't

need anyway

• note - this may not be the best solution. Using

wl_surface_set_opaque_region on our surface would allow the compositor
to optimise rendering as it knows it does not need to show anything
hidden by the window. In testing this works but requires linking to
libwayland-client and including Qt private headers (which is far from
ideal)

• Fixes #13483

(cherry picked from commit b6e7e18a4c209a0dd246c4624db918af0d5152ff)

[wberrier]

I'm still seeing this on Fedora 38 under wayland.

The workaround that worked was to use the "-platform xcb" command line arguments.