Bug 442386 - Prefer EGL to GLX for GL support also on X11
Summary: Prefer EGL to GLX for GL support also on X11
Alias: None
Product: kwin
Classification: Unclassified
Component: glx (show other bugs)
Version: 5.18.7
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
Depends on:
Reported: 2021-09-13 15:33 UTC by C. Leu
Modified: 2022-01-19 08:01 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description C. Leu 2021-09-13 15:33:27 UTC
Hi to all

Okay, this is more a "feature request" than a bug report. After intensive testing, especially on older Apple Intel iMac computers, I must say that a switch to the EGL backend would make absolutely sense. This will improve in some cases dramatically the entire user experience of the GUI on older hardware.

I can confirm this for the old Apple iMac 5,1 series were Kubuntu 20.04 LTS has to be installed via CSM Bios emulation. When the normal GLX backend is used for compositing, the GUI hangs reproducible after login. This happens always right after the "notification message" regarding the WiFi status is displayed. When I start then the terminal via alt + F2 I can see in dmesg the message "kworker blocked for more than 120 seconds". This "GLX hanging problem" is also present when a copy action is started from a network share.

However, a switch to the EGL backend fixed the problem. It furthermore also improves noticeable the overall response of the KDE GUI:

sudo nano /etc/profile.d/kwin.sh

So for me it looks that as for 2021 the EGL implementation is superior to the GLX one. And this is now true also for the X11 window system!

1. Install Kubuntu 20.04 LTS at an iMac 5,1 computer*
2. After the first start-up X is "hanging around" when notifications are displayed

*Currently an install is only possible via CSM Bios emulation. A native EFI installation is not supported because of a "32bit EFI vs. 64bit CPU mismatch". However, there were some changes in later Linux kernel versions (since 5.7) which added a flag called "LOAD_X64_ON_IA32_ENABLE". This would theoretically make a mixed-mode EFI installation possible. But so far I know the Kubuntu devs didn't set that flag on their kernels. As of 2021 only Archlinux seems to have it enabled.

X is under more system-load reproducible hanging (for around 2 minutes) when GLX is used
X is not hanging when EGL is used, also not under higher system-load

X should run fine also with GLX

Linux/KDE Plasma: 5.11.0-34-generic
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8

GPU Hardware: Radeon X1600 series (Mesa 21.0.3, R300 Gallium3D driver used)


It should be noted that also Gnome is "defaulting" X (since four months) to EGL:
Comment 1 Vlad Zahorodnii 2021-09-14 08:07:34 UTC
Currently, all our focus is on Wayland. We would prefer to avoid touching X11 code if possible.

As for making EGL default, on X11, kwin has no any way to determine when a buffer swap completes. For some people, it may be an issue because it can result in stuttering.
Comment 2 C. Leu 2021-09-14 11:27:10 UTC
Thanks Vlad Zahorodnii for your replay.

I have now switched in kwin the compositing of all my Kubuntu 20.04 LTS installations to OpenGL ES / EGL and noticed so far no issues regarding any sort of stuttering. Maybe I will see a "buffer swap" problem sometimes in the future... ;-) How can I provoke it?

Furthermore I enabled the X11 EGL option even in Firefox, - also here no issues so far just a benefit in the overall behavior.

However, it could be possible that this problem described here is not only a "GLX" problem but also one of the "notification system". As mentioned, the message "kworker blocked for more than 120 seconds" has not occurred so far with EGL backend enabled. But when the RAM memory is quite full, then I have sometimes still some "hangers" for example in Dolphin. So I decided to disable the notifications completely, only the critical ones are allowed. After this setting there were no more hangers present, - strange but interesting.

Whatever, it should be noted that this problem may be primary relevant for systems with low RAM memory. My iMac 5,2 has just 4GB physical RAM installed, but Apple enables in legacy CSM Bios mode only around 3GB which is effectively too less for Kubuntu 20.04 LTS. Apple furthermore also screws down the speed of the SATA controller to UDMA133, which is just ridiculous because it limits totally my Crucial MX200 SSD.

These points can be only resolved thorough a installation of Kubuntu in native (mixed-mode) EFI.

Whatever, back to the original matter. As for now I have switched to the EGL backend at the following Apple computer models. I noticed an improvement in the KDE GUI behavior at all of them.

iMac5,1 (4GB RAM, only 3GB usable, R300 Mesa 21.0.3)
iMac8.1 (6GB RAM, native EFI, R600 Mesa 21.0.3)
iMac9,1 (8GB RAM, native EFI, R600 Mesa 21.0.3)
Comment 3 C. Leu 2021-09-21 19:47:54 UTC
Here follows a short status update.

Just for reference, - until now I was NOT able to reproduce any sort of a "stuttering effect" with the EGL backend.

In the meantime I switched at a further iMac computer running Kubuntu 20.04 LTS (and containing a Radeon 6770M GPU) to the OpenGL ES / EGL backend. Also here, no negative side-effect, just a benefit in the KDE Plasma GUI behavior:

iMac12,2 (16GB RAM, native EFI, R600 Mesa 21.0.3)

I searched at the web regarding this EGL/GLX matter and found the information that Firefox 94 will make EGL to its default:

However, this is true only if Mesa 21.x driver version (or higher) is present. Fortunately that's the case for an up-to-date Kubuntu 20.04 LTS installation. ;-)

I also found some information which indicates that the mentioned EGL "stuttering effect" may be more an issue of the proprietary Nvidia Linux driver. Regarding the Radeon side I can confirm for Mesa 21.0.3 that the OpenGL ES / EGL backend runs great on several quite different older Radeon GPUs. The most impressive benefit I noticed at my oldest and weakest iMac5,1 computer. The usability jumped from "not really usable" to almost "perfectly usable" in near any office-work related scenario.

So out of my perspective as a Linux user I simply don't understand why there exist no "user-friendly way" to enable the OpenGL ES / EGL option in the compositor. It doesn't have to be the default setting. Just an option to play with it. ;-) Whatever, I know this will all change with Wayland but I assume that this bigger "switchover" will then probably also exclude some older hardware.

My conclusion is therefore, it's time to change to EGL also on X11! Well, - at least for systems with the awesome Mesa drivers... ;-)
Comment 4 C. Leu 2021-11-01 20:15:23 UTC
Again a short update. During the last few weeks it has been shown that the best way to enforce EGL in kwin is through the "KWIN_OPENGL_INTERFACE=EGL" and not the "KWIN_COMPOSE=O2ES" variable.

This will effectively keep the OpenGL 2.0 or OpenGL 3.1 "function feature set" and just force EGL over GLX.

sudo nano /etc/profile.d/kwin.sh

The first mentioned "KWIN_COMPOSE=O2ES" environment variable is also applicable but it will additionally switch the compositing to OpenGL ES 2.0. Just to be clear, this is perfect for weaker hardware like single core Netbooks, AIO computers, or older systems with limited GPU functionality. Such lower-end systems may benefit significantly from the OpenGL ES 2.0 mode, like the previously mentioned Apple iMac5,1 from 2006.

However, the OpenGL ES 2.0 compositing may limit in certain situations some enhanced graphical effects of a theme. I can confirm this now for the "Se7en Aero" global design which shows partially missing elements. For example, all frames in dolphin are becoming "transparent". This is not the case regarding the regular OpenGL backend in conjunction with EGL. It should also be noted that this is not the case for the standard (more basic) KDE designs "Breeze" and "Breeze-Dark", - they work fine even with only OpenGL ES 2.0 feature set.

Whatever, maybe there will be in the future beside a Vulkan additionally also an OpenGL ES 3.0 rendering backend, - it would allow more effects on weaker hardware. ;-)