At periodic intervals I am getting a crash with the screen becoming empty except for a cursor. If I click anywhere in the screen it will come back and everything is fine again. The interval is random sometimes happening two or more times in a row while at other times not occurring for hours. The systemd journal shows the following messages: May 02 07:37:54 rock-5b-1 kwin_wayland[3409]: kwin_scene_opengl: 0x2: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) May 02 07:37:54 rock-5b-1 kwin_wayland[3409]: kwin_scene_opengl: 0x2: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) May 02 07:37:54 rock-5b-1 kwin_wayland[3409]: kwin_scene_opengl: 0x2: GL_INVALID_OPERATION in glDrawArrays These three messages repeat many times. I can't say for sure they are associated with the screen disappearing but they are the only messages from either dmesg or systemd journal. They only seem to appear when the screen crash has occurred so the odds seem likely that it is related. I am running on a Radxa Rock-5b using an Armbian Ubuntu Noble build. I build Qt 6.7.0 and Mesa 24.1 RC2 Debian packages myself and those are what I am using. I used kde-builder to build a Plasma 6 installation from those. It works pretty well except for this periodic crash of the display.
> If I click anywhere in the screen it will come back and everything is fine again That's pretty weird. Does it ever happen while you have something continuously updating on the screen? Like glxgears maybe?
I'm running what I'd say are standard apps. My typical apps active when this happens would be Chromium, Konsole and perhaps Visual Studio Code although I'm sure I've seen the crash without VSCode running also. One, or more typically both, of the other two are at least running when the crash may occur. I've tried turning on some additional debugging messages for kwin but nothing useful has shown up even when I've seen the aforementioned crashes.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Does your KWin build have https://invent.kde.org/plasma/kwin/-/commit/8c3332f6195dcf213c481c28ddbff680f20a20a9 in it?
(In reply to Zamundaaa from comment #4) > Does your KWin build have > https://invent.kde.org/plasma/kwin/-/commit/ > 8c3332f6195dcf213c481c28ddbff680f20a20a9 in it? Yes it does have that commit.
This looks very driver-specific, as we have don't have any other reports. Next time this occurs can you run dmesg and look for anything graphics related.
Unfortunately nothing visible in the dmesg log around the time of the event at all. The last event is 20 minutes prior to the black screen occurring.
To reiterate/confirm. The only messages that appear around the time of the event are these: Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_ALPHA) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_ALPHA) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glDrawElements Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glDrawElements Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glDrawArrays Jun 06 13:33:06 rock-5b-1 kwin_wayland[3534]: kwin_scene_opengl: 0x3: GL_INVALID_OPERATION in glVertexAttribPointer(no array object bound) It goes on for this quite a long ways. It may be doing this until I click somewhere appropriate on the screen (or click enough times on the screen I am not sure). If I don't click on the screen it stays black (except for the cursor).
Something must be deleting or at least un-binding the VAO. Can you see any pattern for when this would happen, like it only happening while the overview or some specific effect is active? Also, do you use any non-default window decorations?
(In reply to Zamundaaa from comment #10) > Something must be deleting or at least un-binding the VAO. Can you see any > pattern for when this would happen, like it only happening while the > overview or some specific effect is active? > Also, do you use any non-default window decorations? So, to start with the most important information I think somewhat accidentally I did figure out what triggers this blank screen (or at least one trigger for sure) moving the cursor to the top left corner. I get a blue glow and the screen goes black, except for the cursor which as I mentioned remains visible. Sometimes if I move the cursor to the top left corner again the screen will come back on while other times it appears I need to click on the display as I mentioned in prior posts. I'm not sure what options I might have turned on that have to do with the top left corner. I searched in the System Settings but nothing jumped out at me. A Google search found some information related to hot spots but this doesn't seem to be the same in Plasma 6. I'm not knowledgeable enough to know what the VAO is. :-( I believe I'm just using unmodified Breeze Twilight theme if that answers the custom decorations question.
(In reply to Jonathan L Hanmann from comment #11) > (In reply to Zamundaaa from comment #10) > > Something must be deleting or at least un-binding the VAO. Can you see any > > pattern for when this would happen, like it only happening while the > > overview or some specific effect is active? > > Also, do you use any non-default window decorations? > > So, to start with the most important information I think somewhat > accidentally I did figure out what triggers this blank screen (or at least > one trigger for sure) moving the cursor to the top left corner. I get a blue > glow and the screen goes black, except for the cursor which as I mentioned > remains visible. Sometimes if I move the cursor to the top left corner again > the screen will come back on while other times it appears I need to click on > the display as I mentioned in prior posts. I'm not sure what options I might > have turned on that have to do with the top left corner. I searched in the > System Settings but nothing jumped out at me. A Google search found some > information related to hot spots but this doesn't seem to be the same in > Plasma 6. > > I'm not knowledgeable enough to know what the VAO is. :-( > > I believe I'm just using unmodified Breeze Twilight theme if that answers > the custom decorations question. p.s. I confirmed I get the messages on the journal when I do this so it definitely appears to be triggering the same failure mode.
Okay, that narrows it down a lot. If you press Meta+W while the screen is black, does that fix it as well? Also, please attach the output eglinfo and "qdbus org.kde.KWin /KWin org.kde.KWin.supportInformation" here
(In reply to Zamundaaa from comment #13) > Okay, that narrows it down a lot. If you press Meta+W while the screen is > black, does that fix it as well? > > Also, please attach the output eglinfo and "qdbus org.kde.KWin /KWin > org.kde.KWin.supportInformation" here I assume meta is the Windows key? If so then yes that appears to make the screen return to normal. The eglinfo and qdbud is also attached.
Created attachment 170384 [details] Output from eglinfo and qdbus
aha, OpenGL 3.1. I remember having issues with that before... If you throw KWIN_COMPOSE=O2ES into /etc/environment and reboot, does that fix it?
(In reply to Zamundaaa from comment #16) > aha, OpenGL 3.1. I remember having issues with that before... If you throw > KWIN_COMPOSE=O2ES into /etc/environment and reboot, does that fix it? Sorry for the delayed response. I was building Qt 6.7.1 packages for my system. That KWIN_COMPOSE did indeed appear to fix the black screen problem. The Overview screen appears to open ok now. I will monitor it during the day and see if I ever get the black screen again. I'll let you know if it recurs of course. Any downsides to using OpenGLES instead of OpenGL for the KWIN compositor?
Good, then this should be at least easy to work around in KWin (if max. version is 3.1, force 3.0 instead). I'll look into properly fixing it first though... > Any downsides to using OpenGLES instead of OpenGL for the KWIN compositor? Color management (if you enable HDR or set a color profile in the display settings) is currently pretty broken with OpenGL ES and there might be some code paths that are less efficient with the 2.0 version, but generally there isn't a big disadvantage.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5887
That merge request *should* fix the issue properly. I'm not 100% certain though, it would be great if you could compile it yourself and confirm it
(In reply to Zamundaaa from comment #20) > That merge request *should* fix the issue properly. I'm not 100% certain > though, it would be great if you could compile it yourself and confirm it OK. Rebuilding KWIN now. I will let you know the results shortly on the new bug fix. p.s. I also forced MESA to OpenGL V3.0 and that also seemed to solve the problem as you anticipated so some further confirmation there. Thanks for all your help on this!
*** Bug 483783 has been marked as a duplicate of this bug. ***
(In reply to Zamundaaa from comment #20) > That merge request *should* fix the issue properly. I'm not 100% certain > though, it would be great if you could compile it yourself and confirm it It did not appear to fix the issue. I built only KWIN using the following command: kde-builder --resume-from=kwin kwin No errors and I confirmed that the fix in the in log for my local kwin now. Unless I need to do a complete dependencies build for kwin, this does not appear to be a fix for my reported issue unfortunately.
I added a few debug prints to the merge request, could you try with that and tell me what it prints when you try to show the overview?
(In reply to Zamundaaa from comment #24) > I added a few debug prints to the merge request, could you try with that and > tell me what it prints when you try to show the overview? I am not seeing any of your messages in the journalctl -xe log. The changes do appear to be in the eglplatformcontext.cpp file and the build got no errors and installed correctly. In checking the build log it did rebuild that file specifically so I'm a bit confused what is going on.
(In reply to Jonathan L Hanmann from comment #25) > I am not seeing any of your messages in the journalctl -xe log. Most of KWin's logging isn't visible in there; you'll want to use > journalctl --user-unit plasma-kwin_wayland --boot 0 instead
(In reply to Zamundaaa from comment #26) > (In reply to Jonathan L Hanmann from comment #25) > > I am not seeing any of your messages in the journalctl -xe log. > Most of KWin's logging isn't visible in there; you'll want to use > > journalctl --user-unit plasma-kwin_wayland --boot 0 > instead A newly learned thing! ;-) Still nothing however, see attached log file from that command. I deleted the build directory for kwin and am trying another build now. Just in case it didn't rebuild binaries or some silly thing. I keep confirming the two cherry-picked commits are in the source code which they are.
(In reply to Jonathan L Hanmann from comment #27) > (In reply to Zamundaaa from comment #26) > > (In reply to Jonathan L Hanmann from comment #25) > > > I am not seeing any of your messages in the journalctl -xe log. > > Most of KWin's logging isn't visible in there; you'll want to use > > > journalctl --user-unit plasma-kwin_wayland --boot 0 > > instead > > A newly learned thing! ;-) > > Still nothing however, see attached log file from that command. I deleted > the build directory for kwin and am trying another build now. Just in case > it didn't rebuild binaries or some silly thing. I keep confirming the two > cherry-picked commits are in the source code which they are. Oops. When I scanned the entire log I found the messages. Not paying enough attention. I will attach the log as soon as I get trim out the unnecessary bits and make it fit in the size limits.
Created attachment 170443 [details] systemctl log for kwin_wayland
aha, the forward compatible thing isn't available in OpenGL 3.1. I just special cased 3.1 with an added commit now; does that work?
Created attachment 170444 [details] systemctl log for kwin_wayland (with round 2 debug)
(In reply to Zamundaaa from comment #30) > aha, the forward compatible thing isn't available in OpenGL 3.1. I just > special cased 3.1 with an added commit now; does that work? New log posted. Still getting a black screen with Overview.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6018
Git commit 280594354cd070ce99c2b24dfbfbdd0ae498341d by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 28/06/2024 at 12:50. Pushed by vladz into branch 'master'. plugins/qpa: set deprecated functions option correctly If a context is forward compatible, that means the deprecated functions are not available, and if the QSurfaceFormat::DeprecatedFunctions option is set, that means they are available. Wrongly setting QSurfaceFormat::DeprecatedFunctions thus causes Qt to use OpenGL in a way the context doesn't actually support. M +1 -1 src/plugins/qpa/eglplatformcontext.cpp https://invent.kde.org/plasma/kwin/-/commit/280594354cd070ce99c2b24dfbfbdd0ae498341d
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6021
Git commit 2021529a7ff7ac63f7ceb3aed85af6a20fe77ace by Xaver Hugl. Committed on 28/06/2024 at 13:15. Pushed by zamundaaa into branch 'Plasma/6.1'. plugins/qpa: set deprecated functions option correctly If a context is forward compatible, that means the deprecated functions are not available, and if the QSurfaceFormat::DeprecatedFunctions option is set, that means they are available. Wrongly setting QSurfaceFormat::DeprecatedFunctions thus causes Qt to use OpenGL in a way the context doesn't actually support. (cherry picked from commit 280594354cd070ce99c2b24dfbfbdd0ae498341d) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +1 -1 src/plugins/qpa/eglplatformcontext.cpp https://invent.kde.org/plasma/kwin/-/commit/2021529a7ff7ac63f7ceb3aed85af6a20fe77ace
I managed to reproduce this problem with the Mesa override to set the OpenGL version to 3.1, but I haven't found a proper solution so far
On an Nvidia gpu after the latest updates to KDE now if I enable HDR and reboot I am greeted with black screen with same GL_INVALID_OPERATION errors in journal unless I remove the json file for the displays and then have everything reset. Operating System: CachyOS Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.3-3-cachyos (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor Memory: 31,3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2 Driver: 555.58.02
(In reply to kodatarule from comment #38) > On an Nvidia gpu after the latest updates to KDE now if I enable HDR and > reboot I am greeted with black screen with same GL_INVALID_OPERATION errors > in journal unless I remove the json file for the displays and then have > everything reset. I believe the nvidia issue gives a different error set, and the broken config is due to the "wideColorGamut" set to true, changing it to false stops me crashing. I don't think they are related, but I have a full log of it locking up my system should you need it. it's entirely composed of: kwin_wayland_drm: Checking test buffer failed! followed by kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT" a few times and then shows the first error again. It loops over and over one thousand one hundred times per second or so.