OpenGL 2.0 and OpenGL 3.1 stopped working as the compositor backend after an update. XRender does work. When attempting to set the compositor backend in System Settings | Hardware | Display and Monitor | Compositor, it appears to set correctly (i.e: no errors are prompted), however ---- [user@host ~]$ qdbus org.kde.KWin /KWin supportInformation | grep -i compos Composite: yes; Version: 0x4 compositingMode: 1 useCompositing: true compositingInitialized: true windowsBlockCompositing: true Compositing Compositing is active Compositing Type: XRender ---- I'm not able to enable certain desktop effects such as Magic Lamp, Wobbly Windows, etc, so it's obvious XRender is actually in use.
Created attachment 111234 [details] qdbus org.kde.KWin /KWin supportInformation > Kwin-info.txt Attached supportInformation
Created attachment 111235 [details] glxinfo
pacman -Q | grep nvidia lib32-nvidia-340xx-utils 340.106-1 lib32-nvidia-cg-toolkit 3.1-5 nvidia-340xx 340.106-15 nvidia-340xx-utils 340.106-1 nvidia-cg-toolkit 3.1-4
OK, so I did find a thread in the ArchLinux forums: https://bbs.archlinux.org/viewtopic.php?id=235021 it appears the offending package is libepoxy 1.50-1. Downgrading to a previous version of libepoxy (1.4.3-1) allows me to use OpenGL as a rendering backend for Compositing. I'm not sure if this is a valid bug in this case.
I can confirm this bug. It happeneded after an update of libepoxy from 1.4.3 to 1.5.0. I don't know if this is a libepoxy or kwin issue.
Don't confirm it, unless you know the issue is indeed in kwin.
For all we know we can be certain it is not an issue in KWin. If updating a dependency breaks KWin it's either an issue in the updated dependency or in the distribution providing the dependency. Obviously it's bad style of the distribution to ship out a version which breaks KWin. This could be prevented by using openQA as openSUSE does.
*** Bug 391328 has been marked as a duplicate of this bug. ***
While I agree that a distro update breaking the dependecy is most certainly not in the greatest of styles and in that regard, there is something left to be desired, it is worth noting that if the issue really is some interface change in libepoxy, then the solution certainly is not for KWin to keep at the mercy of old and depreciated dependencies forever. If the libepoxy change is not some unfortunate regression that will be solved in the nearest patch, but an intentional change, then we may be upset of libepoxy maintainer all we want for breaking some of the most basic principle not dissimilar to Linux's 'Don't break the userspace - ever', but that doesn't change the fact that it happened. Now, I don't know enough to realize where the real problem is, the worst outcome would be when the users are caught between tho hard heads. I just hope the issue gets solved quickly and for that I'm participating in a way I've been told is most helpful for a non-developer - bug reporting (or in this case just participating, I guess). I'm sorry for being slightly hotheaded and marking the issue as confirmed without much proof. I'll try to be more composed next time.
According to OpenSUSE KDE developers, it could be specific to NVIDIA binary drivers.
One thing that would help narrow down whether this is a bug in epoxy or in kwin would be to verify whether epoxy is behaving as expected in both 1.4.3 and 1.5.0. To that end, I've ported glxinfo to epoxy: https://github.com/nwnk/epoxyinfo If someone experiencing this issue could build and run that (meson setup build, ninja -C build, ./build/epoxyinfo) against both 1.4.3 and 1.5.0, and attach the output from that and from glxinfo, that would likely help identify where the issue is. The cases would be: 1) epoxyinfo with 1.4.3 and 1.5.0 both match glxinfo: probable kwin bug 2) epoxyinfo with 1.4.3 matches glxinfo, 1.5.0 is unique: epoxy bug 3) epoxyinfo with 1.5.0 matches glxinfo, 1.4.3 is unique: arguable but unexpected 4) neither epoxyinfo matches glxinfo: extremely unexpected
Created attachment 111251 [details] glxinfo-libepoxy143
Created attachment 111252 [details] epoxyinfo-libepoxy143
Created attachment 111253 [details] glxinfo-libepoxy150
@ajax: See attachments. glxinfo and epoxyinfo @ libepoxy-1.4.3 and glxinfo @ libepoxy-1.5.0. Interestingly, epoxyinfo @ libepoxy 1.5.0 segfaults.
(In reply to JonnyRobbie from comment #15) > @ajax: > > See attachments. glxinfo and epoxyinfo @ libepoxy-1.4.3 and glxinfo @ > libepoxy-1.5.0. All essentially identical, good. > Interestingly, epoxyinfo @ libepoxy 1.5.0 segfaults. Less good! Can you get a backtrace from gdb for this crash? Preferably with epoxy's debugging symbols installed.
Do you want debugging symbols from epoxyinfo or libepoxy? Because it seems that I'm not able to build libepoxy-1.5.0. see https://github.com/anholt/libepoxy/issues/160#issuecomment-371422087
(In reply to JonnyRobbie from comment #17) > Do you want debugging symbols from epoxyinfo or libepoxy? Because it seems > that I'm not able to build libepoxy-1.5.0. see > https://github.com/anholt/libepoxy/issues/160#issuecomment-371422087 libepoxy. You managed to build it _somehow_ to get that segfault, right? If your problem is that meson check fails, just don't do that.
No, the 1.5.0 I'm getting the main trouble is a precompiled binary from arch repos, which I can get to install, but gives me trouble, but presumably without debug symbols. I'm not able to build 1.5.0 on my own to get debug symbols in. I could patch out the offending commit I found in the bisect, but that would bias this whole thing, I think.
(In reply to JonnyRobbie from comment #19) > No, the 1.5.0 I'm getting the main trouble is a precompiled binary from arch > repos, which I can get to install, but gives me trouble, but presumably > without debug symbols. I'm almost certain arch has debuginfo packages.
(In reply to ajax from comment #20) > I'm almost certain arch has debuginfo packages. No, Arch is the only distro not providing debug packages. It's a sad story :-(
Arch is somewhat a hybrid between source based and binary based distros. The main repos are binary, but you can use it's ports-like system and build easily for yourself if you need some advanced compile-time options, like debug symbols etc. I managed to build 1.5.0 by skipping the check() routine. Will post trace as soon as possible.
As a commit got bisected in libepoxy I'm marking this bug as upstream.