| Summary: | Aurorae-based windecos vanishing with libglvnd | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Duncan <1i5t5.duncan> |
| Component: | aurorae | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | eugene.shalygin+bugzilla.kde, freaky |
| Priority: | NOR | Flags: | 1i5t5.duncan:
Wayland-
1i5t5.duncan: X11+ |
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=422342 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
debug patch
kwin_x11 --replace output, switching windeco oxygen > plastik > oxygen Picture of titlebar issues |
||
|
Description
Duncan
2020-08-27 11:30:06 UTC
Adding the upstream kwin bug URL here as a comment and to the URL field: https://bugs.kde.org/show_bug.cgi?id=425864 (In reply to Duncan from comment #1) > Adding the upstream kwin bug URL here as a comment and to the URL field: > https://bugs.kde.org/show_bug.cgi?id=425864 Oops, wrong bugzi tab! =:^) So I've been working on switching to wayland and am far enough plasma-wayland's my default environment now. I got wondering about this bug and forgot that it was X/libglvnd related and that I was on wayland, so thought I'd test it. Sure enough, I had aurorae-based titlebars again! =:^) Then I remembered I was on wayland, and being in a convenient task lull so I could restart plasma in X mode, tested it back on X as well. Unfortunately the bug continues to exist there. =:^( Fortunately I've both patched up Oxygen windecos to find them of acceptable height now (bug #425874) and prettier as well, so aurorae-based windecos don't matter so much now, and after adapting various scripts/configs and in some cases adjusting workflow, am finding wayland, now usable. While wayland still has many bugs and some stability issues, it doesn't have /this/ bug, and X-only bugs aren't a big deal for me any more either. Extra fortunate since this bug doesn't seem to be getting anywhere... Well if nothing else in a few years as people switch to wayland I suppose it can be resolved/obsolete, but thought I'd add this update anyway, since it does confirm the expected, that the problem doesn't appear on wayland. Setting flags +X11 -wayland Switched to kde/plasma on wayland now. Generally only starting plasma on X when testing whether some bug showing up on wayland is on X as well, but (as commented on the 18th) the problem was still there on X as of a few days ago. Created attachment 133628 [details]
debug patch
Can you apply the attached patch and check if there is any "Aaaaaaargggggghhh! OpenGL context is not valid" message printed in the terminal? (you would need to run kwin_x11 --replace in terminal after applying the patch)
Created attachment 133731 [details] kwin_x11 --replace output, switching windeco oxygen > plastik > oxygen (In reply to Vlad Zahorodnii from comment #5) > Can you apply the attached patch and check if there is any > "Aaaaaaargggggghhh! OpenGL context is not valid" No such message (and I double-checked my build log to be sure the patch had applied). There's some nasty-looking output logged but not that. But in case it's useful... Here's the log from a kwin_x11 --replace >kwin.debug 2>&1 , while already having the windeco kcm open so I can immediately test switching to an aurorae-based one. I did the replace with the windeco set to oxygen, switched it to plastik, applied, switched it back to oxygen, applied, and did another replace to stop logging. The first set of OpenGL/Mesa/etc info is from the initial replace. The second is triggered by the apply after switching to plastik. You can see the nasty-looking output after it from trying to load plastik (my previously preferred aurorae-based blacksquare has similar output, but plastik is the kde-shipped aurorae-based windeco so I did the log with it). The third is from the apply after switching back to oxygen -- no nasty output. (The final three lines of XCB BadWindow errors are unrelated; I was launching recursive pdmenus in konsole to run the final replace from there.) (I'm pretty much switched to wayland now, having hack-patched a local workaround to the last real irritating bug #429177 on that today. So I quit plasma/wayland to CLI (no *DM installed here) and start plasma/X to test X-side-only bugs like this, now. I had my brain full of wayland bugs, workarounds and hack-patches with the switch so it took me a few days to apply this patch and get a log.) > QQuickRenderControl::initialize called with incorrect current context
Okay, this sort of explains why window decorations vanish. But still, it doesn't explain why there's no current opengl context.
Either EffectQuickView fails to create an offscreen surface, or something goes wrong while it tries to make the context current.
Running into this issue as well. I got a Dell XPS 15 9550 however (intel / nvidia hybrid). Seems pretty much independent of the hardware thus considering Duncan has AMD. Created attachment 135745 [details]
Picture of titlebar issues
Same problem with an old Intel Haswell:
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2) (0x416)
Version: 21.0.0
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.0.0-rc5
OpenGL core profile shading language version string: 4.50
Works on Gentoo after libglvnd upgrade to 1.4.0. Anyone else still seeing this bug? Pending that I'm setting status to NEEDSINFO/WAITINGFORINFO FWIW I've been wayland-only for awhile now and in fact don't have xorg installed at all any longer -- the only X I have is xwayland on kwin_wayland (with weston as a backup compositor), so for me this is obsolete. I believe the needsinfo/waitingforinfo status will auto-resolve after a few weeks if nobody says they're still seeing it and resets the status. 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! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone! |