Hi there,

I use KDE 5 on openSUSE Leap 42.1 and I wanted to give EGL a try.
I use a Geforce 640 with driver 352.79. As I understood, this driver should support EGL.

But, when enabling OpenGL 3.1 with EGL, kwin_x11 gives this message:

Code: Select all

kwin_core: bind OpenGL API failed
kwin_core: Failed to initialize compositing, compositing disabled


How do I test, whether the Nvidia driver really supports EGL?
And how do I now correctly enable EGL with KDE5?

I read somewhere, EGL is the future and this is the only reason why I tried to get it working....

Thanks

EGL isn't supported in your driver, starting with 355.x, there's *EXPERIMENTAL* EGL support, though i've not actually checked whether it suffices our requirements.

EGL is simply a platform agnostic GL API, there's no direct user benefit from using it, so don't worry.

fyi - I briefly tried the 358,x drivers and they seemed to work but there was no compositing

luebking wrote:EGL is simply a platform agnostic GL API, there's no direct user benefit from using it, so don't worry.

But one day I guess KDE will switch to EGL I read in a blog.
Do AMD drivers already support EGL?
I may switch to an AMD card anyway, from what I hear people have smoother KDE experience with KDE, e.g. no plasma/kwin crashes.

Folks who have kwin5/plasma5 crashes almost always have a Nvidia card... this makes me think about AMD.

You guess you read that in a blog? =)
Don't worry, we're not dropping glx before egl somehow matured.

Ppl. encountering nvidia crashes usually suffer from a cross installation of the nvidia and the mesa drivers.
Ensure your AMD GPU is fully supported by the open source drivers, fglrx is terrible - nvidia is actually still the least troublemaker.

I'll check where the egl init fails on the nvidia blob (but again: whether you're using egl or glx does absolutely not matter for *you* - only for us to find bugs in the EGL implementation

luebking wrote:Ppl. encountering nvidia crashes usually suffer from a cross installation of the nvidia and the mesa drivers.

That makes me curious now.
How can one check if there is a Mesa / Nvidia driver mess?
Should one remove certain parts of Mesa after installing proprietary Nvidia drivers?
My impression was, the Nvidia driver installer takes care of everything automagically...

Thankx

It does.

The common patterns are
a) nouveau installed and not blacklisted (causing concurrent access to the GPU and once nouveau/kms touched it, things go south)
b) MESA and MESA GL installed via package manager, installed nvidia on top from the nvidia installer. Mesa gets an update and overrides the libGL links.
c) Distro packaging allows to install MESA GL and nvidia libGL (eg. if there's only one MESA packge or similar)
d) Inept user trying to fix the above
e) to some degree the usage of a framebuffer console https://wiki.archlinux.org/index.php/GR ... ramebuffer

Yes, this is true.
After major X updates I usually have to install the Nvidia drivers again anyway....
I guess in terms of stability it seems it´s not much difference if you chose AMD or Nvidia.
AMD looked more promising to me, because they seem to want to put more support into open source and community. This deserves support from customer side IMHO.

The OSS radeon drivers and AMDs recent effort for a common kernel module are ok, but do yourself a favor and stay far away from fglrx