We are currently approaching the release of the first alpha version of KWin 5. This is of course a significant milestone and we have put lots of work into the transition to ensure that it’s already working quite fine. With such a big migration it is also important to not only work on new cool stuff, but also to do lots of house cleaning.
For example last week the build option for disabling scripting support got removed as we consider scripting as an important and integrated part of KWin. Thus during the house cleaning the build option got removed.
And of course there are areas where we wanted to remove some legacy code for quite some time but never really dared to do. Two years ago I already discussed the costs of supporting the legacy OpenGL 1 compositing backend. Now it was time to re-evaluate the situation.
KWin 5 is a strong user of QtQuick 2. In fact almost all user interface code is written with this new framework – be it the close button in Present Windows, the window switcher or (since today) the outline shown when using quick tiling/maximization. QtQuick 2 uses an OpenGL (ES) 2 powered scene graph thus KWin already has a runtime dependency on OpenGL 2. And in opposite to our Compositor this is a required dependency. While it has always been possible to disable the Compositor (and that won’t change for X11), it is not (yet) possible to disable the OpenGL usage of QtQuick.
Thus we have to ask whether it’s still worth keeping a code path for legacy hardware, if we require newer hardware. Combined with all the problems mentioned in the above linked blog post from two years ago it becomes really questionable to keep the code.
After some preparation to ensure that we have a clean cut I pushed today the changes to remove the legacy OpenGL 1 compositor in order to have this change in Alpha 1. We encourage all users who used to run the OpenGL 1 compositor to try with the OpenGL 2 compositor and also with the still supported XRender based compositor. If you run into any severe issues please report a bug (or check whether one has already been reported) and provide the support information. This will help us to iron out any issues, like ensuring that no effects get loaded which are not suited for your hardware. After all the base OpenGL 2 compositor should not be an issue for most hardware. But some effects are more demanding than the compositor itself and those can be disabled automatically. Also we try to keep the impact low. If our logic recommended OpenGL 1 compositing for a specific set of hardware, it doesn’t enforce OpenGL 2 now, but uses the better suited XRender compositor.
Sounds perfectly reasonable to me.
BTW, s/in opposite to/in contrast to/ .
People with very old hardware usually don’t use the newest software…
I highly doubt any user of the latest KDE uses OpenGL 1…
as you said KWin is a strong user of QtQuick2. However i don’t get how KWin can implement for the cube viewport switch effect. The cube viewport it’s a 3D scene where on top of each face a 2D scene is painted. In this kind of situation i don’t understand the role of QtQuick2:
Is there an external 3D engine that draws the cube and obtain from QtQuick a texture for each face of the cube? Or is it done the other way around?
Thinks like the cube don’t use QtQuick.
Good riddance.
OpenGL 2 is 10 years old, there isn’t much hardware left that benefits from GL1, but cannot support GL2.
The driver situation on linux has improved enough that virtually any machine with a modern GPU has a working opengl 2 implementation today; in many cases even an open source one.
I’d say XRender + LLVMPipe are enough fallbacks, and there’s always the option to use KWin4 with KDE Workspace 5, right?
Hi! It’s OK that it does not support age old hardware, but will it support not using 3D acceleration at all? The Linux 3D drivers of many video cards (including newer ones) are rather sluggish.
You can still use XRender for compositing or no compositing at all. QtQuick 2 is a requirement, though.
QtQuick 2 works with llvmpipe though, and I got an environment variable (QT_XCB_FORCE_SOFTWARE_OPENGL) added to Qt (I think) 5.3 that allows forcing LIBGL_ALWAYS_SOFTWARE for Qt 5 apps (and Qt 5 apps only).
Of course, that still means you can’t mix QtQuick 2 with OpenGL 1 compositing on OpenGL-1-only hardware, because LIBGL_ALWAYS_SOFTWARE affects the whole application.
I might just be confused, but when you say “OpenGL 2” you really mean the OpenGL level not something like “second generation OpenGL renderer”, correct? In case you mean the OpenGL level: why not go that step further and only support the OpenGL 3.1 renderer the current KWin already sports? I can also see a good argument for using OpenGL ES exclusively, since that would work across all platforms and KWin shouldn’t use anything/much, that can’t be expressed in that subset.
Anyway: thanks for your work!
Because the drivers are not there yet and there are lots of hardware out there which just cannot do it. Also the differences between the OpenGL 2 and OpenGL 3.1 compositor are rather small and much easier to maintain.
Didn’t understood something, to run KWin 5 (or any QtQuick 2 application), will it require OpenGL 2?
If so, will OpenGL 1.3 hardware (like Intel 8xx chips which where popular in the past) run QtQuick 2 application?
I honestly cannot say as I have never tried to run on such old hardware.
It works with llvmpipe, and we automated the fallback in Fedora (it takes a QT_XCB_FORCE_SOFTWARE_OPENGL environment variable that I got added to upstream Qt for upcoming releases and a short xinitrc.d snippet that automatically sets it if only OpenGL 1 is available). It does not work (crashes systematically) with hardware-accelerated libGL on such hardware.
PS: So far, I only tested this with the Qt Quick examples, I have yet to try out KWin 5.
KWin recognizes llvmpipe and doesn’t start GL compositing in that case.
It is true that supporting old hardware is mostly a pain in the neck. Its something that happens in all projects. For instance the Linux Kernel
dropped support for i386 after 21 years when they could have probably done that a little earlier. I don’t even know if the maintenance burden and the added complexity was justified 10 years latter.
I do hope freeBSD catches up with all the software that is required to build KDE5 because it does look like an interesting release.
Thanks for all the effort you and the whole KDE team are putting into it, Martin.
Keep up the good work!
Regards.
so there is no way to have 0 opengl usage in kde5.. i’ll wait ntill kde 6 if you manage to not use opengl everywere( i hate this trend)