Bug 391486

Summary: Epoxy 1.5 breaks OpenGL compositing
Product: [Plasma] kwin Reporter: Dan <dan.f.kriz>
Component: scene-openglAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED UPSTREAM    
Severity: normal CC: ajax, dan.f.kriz, kde-bugs, marcodv, rdieter, stupor_scurvy343, vasyl.demin
Priority: NOR    
Version: 5.12.3   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
See Also: https://github.com/anholt/libepoxy/issues/160
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: qdbus org.kde.KWin /KWin supportInformation > Kwin-info.txt
glxinfo
glxinfo-libepoxy143
epoxyinfo-libepoxy143
glxinfo-libepoxy150

Description Dan 2018-03-06 21:56:29 UTC
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.
Comment 1 Dan 2018-03-06 21:57:24 UTC
Created attachment 111234 [details]
qdbus org.kde.KWin /KWin supportInformation > Kwin-info.txt

Attached supportInformation
Comment 2 Dan 2018-03-06 21:58:00 UTC
Created attachment 111235 [details]
glxinfo
Comment 3 Dan 2018-03-06 21:58:51 UTC
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
Comment 4 Dan 2018-03-06 22:14:22 UTC
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.
Comment 5 JonnyRobbie 2018-03-07 19:15:01 UTC
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.
Comment 6 Christoph Feck 2018-03-07 19:18:37 UTC
Don't confirm it, unless you know the issue is indeed in kwin.
Comment 7 Martin Flöser 2018-03-07 20:41:57 UTC
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.
Comment 8 Martin Flöser 2018-03-07 20:46:34 UTC
*** Bug 391328 has been marked as a duplicate of this bug. ***
Comment 9 JonnyRobbie 2018-03-07 20:59:21 UTC
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.
Comment 10 Christoph Feck 2018-03-07 21:24:35 UTC
According to OpenSUSE KDE developers, it could be specific to NVIDIA binary drivers.
Comment 11 ajax 2018-03-07 22:33:55 UTC
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
Comment 12 JonnyRobbie 2018-03-08 09:34:05 UTC
Created attachment 111251 [details]
glxinfo-libepoxy143
Comment 13 JonnyRobbie 2018-03-08 09:34:41 UTC
Created attachment 111252 [details]
epoxyinfo-libepoxy143
Comment 14 JonnyRobbie 2018-03-08 09:35:13 UTC
Created attachment 111253 [details]
glxinfo-libepoxy150
Comment 15 JonnyRobbie 2018-03-08 09:37:58 UTC
@ajax:

See attachments. glxinfo and epoxyinfo @ libepoxy-1.4.3 and glxinfo @ libepoxy-1.5.0.

Interestingly, epoxyinfo @ libepoxy 1.5.0 segfaults.
Comment 16 ajax 2018-03-08 14:41:45 UTC
(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.
Comment 17 JonnyRobbie 2018-03-08 15:24:45 UTC
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
Comment 18 ajax 2018-03-08 16:02:39 UTC
(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.
Comment 19 JonnyRobbie 2018-03-08 16:16:03 UTC
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.
Comment 20 ajax 2018-03-08 16:24:22 UTC
(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.
Comment 21 Martin Flöser 2018-03-08 16:35:15 UTC
(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 :-(
Comment 22 JonnyRobbie 2018-03-08 16:45:12 UTC
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.
Comment 23 Martin Flöser 2018-03-09 17:23:12 UTC
As a commit got bisected in libepoxy I'm marking this bug as upstream.