https://bugs.kde.org/show_bug.cgi?id=425864
Bug ID: 425864
Summary: Aurorae-based windecos vanishing with libglvnd
Product: kwin
Version: git master
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: aurorae
Assignee: kwin-bugs-n...@kde.org
Reporter: 1i5t5.dun...@cox.net
Target Milestone: ---
So Gentoo's currently switching from a manual selection of the X/Mesa OpenGL
driver (using Gentoo's eselect-opengl tool) to automatic, using libglvnd.
After doing the necessary rebuilds (mesa and xorg-server, plus switching
between the mutually blocking eselect-opengl and libglvnd) and restarting
X/plasma, my windecos were all transparent!
After various troubleshooting, it seems all aurorae-based windecos, including
kwin's native plastik, are affected, while oxygen and breeze work just fine.
Additionally, everything else appears to be fine, so it's only aurorae-based
windecos affected.
I did note that with kwin's blur-behind-semi-transparent effect on, the area
where the windeco should be was blurred (well, just the titlebar, since I have
the no-borders option set). Additionally, while the titlebar buttons are as
invisible as the titlebar itself, they still respond to clicks. (Of course
with blur-behind off, the titlebar area was entirely invisible.)
Hardware/Software:
All frameworks/plasma/kde-apps live-git versions from the gentoo/kde overlay
(-9999 master versions), on a Radeon rx460 card (Polaris11), running the native
freedomware kernel/mesa/xf86-video-amdgpu drivers. Possibly relevant version
numbers: Gentoo/~amd64, Linux 5.8/5.9-rcs (tested/current), Qt-5.15.0,
xorg-server-1.20.8-r1, mesa-20.1.6/20.2.0_rc2 (tested/current).
Further testing revealed that with either the opengl-3.1 or opengl-2.0 backends
set in the compositor kcm, aurorae-based titlebars were transparent, while
xrender, as expected, rendered fine, tho of course slower and disabling
opengl-only effects like wobbly-windows. Disabling compositing of course
rendered the titlebars too, but disabled effects such as zoom and window
transparency that I would have serious trouble doing without (especially
transparency due to old-eyes).
The gentoo/xorg folks suggested I try restarting kwin_x11 from a terminal
window to see if I got any useful diagnostics. Unfortunately, as I pointed
out, most kde apps, kwin_x11 included, spit out all sorts of alarming looking
output even when they're (to all appearances) working just fine so such output
tends to be effectively useless unless you can get a diff between the output in
the good and bad cases. Fortunately I was able to rebuild multiple times for
testing, toggling between eselect-opengl and libglvnd mediated mesa, so getting
the good/bad outputs to diff wasn't /too/ horribly difficult, just
inconvenient.
Unfortunately even the kwin_x11 good/bad output diff, while smaller, was still
incredibly noisy. Manually cutting it down further based on messages the diff
had already excluded, the result was two lines appearing only in the
bad/libglvnd case, in order with some noise in between:
QQuickRenderControl::initialize called with incorrect current context
QOpenGLVertexArrayObject::destroy() failed to make VAO's context current
Further testing indicated that (as one might expect) the ::initialize error
appears at kwin_x11 --replace load time, while the ::destroy() error appears
later, when closing a window.
Typically, regardless of the windeco (so running unaffected breeze/oxygen as
well as affected aurorae-based), kwin_x11 --replace will crash a few times then
come up with the other-wm dialog. With no other wms installed I just hit OK
with the pre-filled kwin_x11, but by then it has restarted without composite
and doesn't crash further. *But* I can then turn composite back on and it
still doesn't crash, aurorae-based windecos simply go transparent, while
oxygen/breeze windecos and kwin effects work normally. I'll only crash kwin
again if I do another --replace, at which point it starts the multi-crash,
return-with-compositing-disabled, renable-compositing to be stable again but
with transparent aurorae-based windecos, routine all over again.
Given that the bug originally triggered with the Gentoo switch to libglvnd
(with the older eselect-opengl masked and set to be removed in a month, now
perhaps 3 weeks), I originally filed a bug there, but the bug now appears to be
in kwin/aurorae, so I'm filing it here.
Two other points of interest on the Gentoo bug are:
1) A gentoo/kde dev tested as well and couldn't duplicate for whatever reason.
He was running a Radeon of some sort, he didn't say what, and versions he said
were similar to mine. I'd guess he's running a newer Radeon and the difference
is either the hardware itself or down to hardware-specific drivers, but of
course on gentoo there's all sorts of possible configuration differences as
well.
And more interestingly and likely to be of value:
2) The gentoo/xorg/mesa dev suggested the problem was likely an uninitialized
opengl context, which the two specific errors in the output suggest as well.
He pointed to this commit correcting a similar context-init omission in
xdriinfo as an example of what might be missing/needed.
https://cgit.freedesktop.org/xorg/app/xdriinfo/commit/?id=6273d9dacbf165331c21bcda5a8945c8931d87b8
Not being a dev I really wouldn't know where to start thinking about how to
apply that to kwin's aurorae engine, but the general idea does seem to fit the
errors I saw in the output and seems reasonable. And if you give me a patch or
simply make the commit in kwin-master I can test it.
Finally, here's the gentoo bug link with various attachments including the full
kwin_x11 --replace output, along with the original troubleshooting I've
summarized above.
https://bugs.gentoo.org/736916
--
You are receiving this mail because:
You are watching all bug changes.
