fix QT>=6.4 segfault by always setting surface type

[mitchcapper]

See #754 for details but this is the recommendation from QT dev @alpqr that 100% WFM. Note, as I mention there officially the old behavior would be best replicated by setting this to the internal value QSurface::RasterGLSurface from https://doc.qt.io/qt-6/qsurface.html#SurfaceType-enum as this is what QT 6.3 and lower did. If you want me to update the PR to that I can. I don't have osx to test there.

Clearly people are running mythtv with QT > 6.3 so I am not sure why only some users hit this bug. Maybe it is only if they have hardware rendering enabled? Given how long it has stood though there must be something scoping it to just a select few of us.

Checklist

• [x ] contribution does not duplicate one of our existing pull requests
• [x ] contribution is in a branch rebased against master
• [x ] code compiles successfully without errors
• [x ] code follows the MythTV Coding Standards
• [ x] documentation added/updated/removed where necessary
• [ x] commits are logically organised and have good commit messages

Fixes #754

[jhoyt4]

This is confirmed to work on macOS with qt 6.8

[linuxdude42]

Doesn't work for me on Fedora.

[mitchcapper]

@linuxdude42 please post full startup logs and run mythfrontend with env var QT_DEBUG_PLUGINS=1

[linuxdude42]

I don't get any additional output when running the qt6 based image with QT_DEBUG_PLUGINS set. I do get output for the qt5 image, so I know I've set the variable correctly. Does the attached excerpt from a strace output help? It shows that the files for the egl plugins are being opened.
log.txt

[mitchcapper]

sorry try this

export QT_DEBUG_PLUGINS=1
mythfrontend -v general,gpu,gui &> myth.log

then attach the myth.log

[linuxdude42]

I hope this helps, but it still doesn't have any qt debug output.
myth.log

[mitchcapper]

Yeah that is pretty lacking, just to confirm before applying this PR you were getting "Qt: QOpenGLContext::makeCurrent() called with non-opengl surface " ?

the 300D error is the same that @warpme gets currently. The EGL error is actually "EGL_BAD_SURFACE" which would imply certainly a similar error to what Qt itself was saying without.

Can you try your graphics cards proprietary driver? Does the display server log have anything potentially useful in it?

[linuxdude42]

Yes, before the patch I get:

Qt: QOpenGLContext::makeCurrent() called with non-opengl surface 0x1753c9e0

and after the patch I get:

Qt: QEGLPlatformContext: eglMakeCurrent failed: 300d

My laptop has Intel's UHD Graphics 630 I am using the Intel i915 driver. I don't see anything useful in the Xorg.0.log file.

I'm happy to compile in any debugging code you think would be useful. I would very much like to get this resolved so we can (hopefully) transition the default compile from qt5 to qt6 after the next release. Feel free to contact me directly.

[linuxdude42]

I see the same 300d error on one of my production frontends. That system is an Intel NUC6 with HD Graphics 500 video using the i915 driver.

[mitchcapper]

In reviewing what was said in #754 at least @kmdewaal also got this error with intel graphics and @warpme is thought to have as well.

@jhoyt4 can you confirm what graphics card is driving the box it worked on? I assume plenty of people are using these on mini pcs thus the intel only graphics but if it does work with amd/nvidia proprietary drivers that would be interesting. At a minimum may make narrowing the problem easier.

[jhoyt4]

Apple GPU on an M1 and M3max

[linuxdude42]

Another data point. Works on my old 2014 Mac Mini running macOS 12.7.6 and using Intel Iris graphics.

[kmdewaal]

Another data point: boty menu and playback is OK under the following conditions:

• export MYTHTV_NO_EGL=1
  (see mythdisplay.cpp:1222)
• use FFmpeg decode ("Normal") instead of VAAPI hardware acceleration

This is with Fedora 41, Qt 6.8.0, master with this fix included.

[warpme]

• export MYTHTV_NO_EGL=1

Indeed - this confirms (for me): issue is within egl based x11 integration layer in qt6(xcb_egl).
I think - as of my last report in https://bugreports.qt.io/browse/QTBUG-113728?focusedId=848677&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-848677 - issue is within qt6 - not in mythtv.

As x11 with xcb_glx and eglfs are working, I'm concluding:

1. mythtv correclty operates with qt6 gl subsystem (eglfs; xcb_glx are working)
2. issue is in internal qt6 xcb_egl gl integration layer

Before Qt6.4 all was working ok - so for me all this points to regression in qt6+

It is a bit sad for me that Qt team seems to be not interested in resolving this issue...