Created attachment 139848 [details] Transparent hamburger menu in Elisa SUMMARY The background of menus and tooltips in QtQuick/Kirigami based apps is transparent, making things very chaotic and hard to read. STEPS TO REPRODUCE 1. Open any QtQuick-based app (e. g. Elisa) 2. Show a tooltip or a menu (e. g. the hamburger menu of Elisa) OBSERVED RESULT The background is transparent. EXPECTED RESULT The background should be a solid colour, as defined in the active colour scheme. Operating System: KDE neon 5.22 KDE Plasma Version: 5.22.2 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.3 Kernel Version: 5.8.0-59-generic (64-bit) Graphics Platform: Wayland
Created attachment 139967 [details] kcm_style transparent menu Another screenshoot (kcmshell5 kcm_style)
Created attachment 140110 [details] System Monitor The new System Monitor is affected as well
Would be really nice if something could be done about this. Transparent menus is rather annoying ;)
Can you confirm if this is X or wayland?
Both platforms are affected.
How odd. 1. Are you using any non-default themes at all? 2. Does it reproduce with the standard Breeze Light color scheme? 3. What kind of graphics hardware are you using?
(In reply to Nate Graham from comment #6) > 1. Are you using any non-default themes at all? Yes. I'm using a custom dark theme (for improved contrast). > 2. Does it reproduce with the standard Breeze Light color scheme? Last time I tried, yes. > 3. What kind of graphics hardware are you using? Intel HD Graphics 4000. Compositing method is OpenGL 3.1.
Just confirmed it does also reproduce with the default schemes.
I wonder whether my QtQuick install might be somewhat damaged in general, because of the strange issues I had/have with the System Monitor (graphs not visible, sometimes unusually high resource demand).
It would seem related, yeah. Please let us know what you discover after some further investigation.
> Please let us know what you discover after some further investigation. What should I look for? I can't remember having done anything unusual that could cause such problems... The issues I had with PySide2 from the Neon repository seem loosely related as well (random segfaults even in very simple code). Classical Qt apps are all right, though.
I don't know, sorry.
The issue still persists after today's kde software updates. I don't have the remotest idea what could be the cause :(
Any ideas, Arjen or Noah?
Created attachment 140711 [details] Even the popup background is transparent (Discover)
If anyone else is affected, please report it here.
Perhaps the GPU driver in KDE Neon is too old. I don't have this issue. Operating System: openSUSE Tumbleweed 20210926 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.6-1-default (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Atom™ x5-Z8500 CPU @ 1.44GHz Memory: 3.8 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics
Indeed, this is ultimately going to be a graphics driver issue. One of the downsides to using a GPU-accelerated UI toolkit is that you end up with exposure to GPU driver bugs. I would recommend that you report this issue to the developers of the GPU driver that you're using.
Not sure whether the driver really is the cause. Yes, it may be possible, but I think you shouldn't rule out a cause in Plasma or Qt without further investigation. I'd rather not consider this issue resolved.
There is no Plasma code involved so it can't be Plasma. There is code in qqc2-desktop-style involved, but I investigated that and there isn't really anything in there that could cause it. Another option is that it's a KWin problem, though this seems unlikely. Does the issue go away if you change your compositing method from OpenGL 3.1 to OpenGL 2.0? If not, then that leaves two possible culprits: - Qt - GPU drivers I suppose it could be a bug in Qt, rather than your GPU drivers. However either way, it's an upstream issue, and not something caused by Qt code. :) My hunch that it's a driver-related issue is because if it was a Qt issue, I would expect it to be much more widespread, but this is the first bug report I've seen about it. In my experience, esoteric and impossible-for-other-people-to-reproduce visual bugs in QtQuick components are always caused by GPU driver problems. So can you try switching to OpenGL 2.0 and seeing if that solves it? If so, it's a KWin issue. If not, It's almost certainly a GPU driver issue.
Switching the compositing method does not affect the bug in any way. I already tried that long ago... I rather thought in the direction of a damaged configuration file issue. I've already had that a few times. If it were random rendering glitches, I would also suspect the graphics driver, but the issue with transparent instead of black background is so systematic that this seems kind of unlikely to me. However, I will file a bug with the graphics developer when I have time. I also thought of reinstalling the system at some point and see whether that fixes some of my impossible-to-reproduce issues.
I think I can now prove your guess that it's an upstream bug in the graphics driver: Running QtQuick apps (e. g. Elisa) with the environment variables `QT_XCB_FORCE_SOFTWARE_OPENGL=1 QT_QPA_PLATFORM=xcb` fixes the problems. (Question: Is there a also Wayland-specific flag to force software OpenGL?)
... however, this didn't work for kcm_style. There it's still the same problem, despite enforcing software OpenGL, so this will probably have a different cause...
> I think I can now prove your guess that it's an upstream bug in the graphics driver: > Running QtQuick apps (e. g. Elisa) with the environment variables > `QT_XCB_FORCE_SOFTWARE_OPENGL=1 QT_QPA_PLATFORM=xcb` fixes the problems. From looking at the console output, when not using the Software OpenGL flag, there are a lot of warnings about "Problematic vertex shader source code" and messages like "This file is intended for desktop OpenGL version 4.5 or greater". So probably the cause is code written for a newer version of OpenGL than what I have: ``` QOpenGLShader::compile(Vertex): 0:14(10): error: GLSL 4.50 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.50, 3.30, 4.00, 4.10, 4.20, 1.00 ES, and 3.00 ES *** Problematic Vertex shader source code *** [...] // This file contains common directives needed for the shaders to work. // It is included as the very first bit in the shader. // Important: If a specific GLSL version is needed, it should be set in this // file. // This file is intended for desktop OpenGL version 4.5 or greater. [...] ```
The main question is, why are you running Core profile? With regards to software rendering, if you're using Mesa the environment variable is `LIBGL_ALWAYS_SOFTWARE=1`.
(In reply to Arjen Hiemstra from comment #25) > The main question is, why are you running Core profile? Sorry, what does this mean? > With regards to software rendering, if you're using Mesa the environment > variable is `LIBGL_ALWAYS_SOFTWARE=1`. That works, thanks!
> The main question is, why are you running Core profile? So apparently there is an OpenGL Core profile and a Compatibility profile. Support for Compatibility profile is optional, and especially some Intel drivers don't support it well. If this is the case, why are you/Qt relying on Compatibility profile if support is not generally available? Could that piece of code be changed to support Core profile and OpenGL <= 4.2? Should I file a bug with Qt? BTW, my GPU is `Mesa DRI Intel® HD Graphics 4000`