The main purpose of the opengl testapp was to set the environment
variable LIBGL_ALWAYS_INDIRECT if direct rendering is not supported
before glx gets initialized.
With Qt5 we may no longer set this environment variable. QtQuick
requires direct rendering. On IvyBridge QtQuick is crashing if the
variable is set. Thus we are no longer allowed to set it and thus the
complete test becomes pointless.
The test app basically whitelisted most drivers anyway, the only
drivers which were problematic are the proprietary Catalyst drivers.
It that's still a problem we can also disable OpenGL compositing on
those drivers through the recommendation in the GLPlatform.
This also means that the KWIN_DIRECT_GL variable is no longer useful.
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
This backend is able to composite on a Wayland surface instead of an X11
overlay window. It can be considered as a prototype for a Wayland session
compositor.
For texture from X11 pixmap the backend uses XShm. This is far from
optimal, but the KHR_image_pixmap extension is not available in Mesa's
Wayland backend. It's a temporary solution till we have XWayland and
texture from Wayland buffer.
To use this backend one needs to specify the environment variable
KWIN_OPENGL_INTERFACE with "egl_wayland". In future KWin should probably
use this backend if the Wayland display env variable is defined.
To use this setup:
1. Have a normal X-Server running on e.g. VT7
2. Start Weston on VT1
3. Start a terminal on Weston
4. start KWin with:
DISPLAY=:0 KWIN_OPENGL_INTERFACE=egl_wayland kwin --replace &
This should map a Wayland surface to Weston showing the content of the X
setup. At the moment it's not yet possible to interact with the surface
as input events are not yet recieved in the backend.
There are still a lot of limitations as documented in the code.
* don't execute OpenGL test app if user selected XRender
* don't execute OpenGL test app if user forces to EGL
If a user selected XRender because OpenGL is failing badly it might not
be the best idea to call an OpenGL application.
If the user enforces EGL it's kind of pointless to call a testapp which
uses GLX.
REVIEW: 110659
This was currently basically broken:
* Screen number got always attached
* openGLIsBroken did not check for screen number
-> KCM reported "everything is fine" while it wasn't
Now changed to:
* only attach screen number if it is a multi-head setup
* use same logic in both Composite and CompositingPrefs
Still problematic:
* kcm is not multi-head aware so it will report everything is fine in
case of a broken multi-head setup
REVIEW: 110631
Many headers included KLocale to use i18n and co. But those methods are
defined in KLocalizedString and not in KLocale.
With KF5 klocale.h does no longer include KLocalizedString causing lots
of compile errors.
The extension handling is removed from kwinglobals and moved into the
xcbutils in KWin core in namespace KWin::Xcb. The motivation for this
change is that the Extensions are only used in KWin core and are marked
as internal. So there is no need to have them in the library.
What remains in Extensions are the non-native pixmaps. This will be
removed once we are on Qt 5 as QPixmap can no longer reference an XPixmap.
The remaining code in kwinglobals also still initialize the XLib versions
of extensions emitting events. It seems like there are no XEvents emitted
if not done so even if the extension is correctly initialized with xcb.
This needs to be removed once the event handling is ported over to xcb.
REVIEW: 107832
Whether creating the OpenGL context succeeds or not
had no influence in any decisions on the used settings
for OpenGL based compositing.
The only valid information CompositingPrefs still detects
is whether direct rendering should be used which is
performed out of process and does not require a context.
So overall the context creation is not needed and can
be removed.
REVIEW: 104778
This means the GLPlatform is filled with values from the
context actually used for Compositing and if XRender
compositing is used no OpenGL information is logged.
There is no need to have it driver specific any more.
All drivers seem to support it (only Intel had been
opt-ed out without any apparent reason shown in commit log).
This was the last driver specific setting which means that
the method applyDriverSpecificSettings() got dropped from
CompositingPrefs.
Strict binding follows the driver (GLPlattform) unless
the user has a config value specified in the kwinrc.
For this a new property is added to Options to indicate
whether strict binding is user defined or follows the
driver. In case of driver the strict binding option is
set when OpenGL compositor starts up.
Due to changes in build system we have always either OpenGL or OpenGL ES.
This allows to remove the KWIN_HAVE_OPENGL_COMPOSITING define. In the
effects the define is kept as KWIN_HAVE_OPENGL which can be used in
future to build also an XRender only effect system.
Building the workspaces requires to have all the build dependencies
which were required for KWIN_HAVE_COMPOSITING to be set. This allows
us to remove all the ifdefs for this and gives us a cleaner code.
The advanced compositing option "direct rendering" could only
correctly be honored in the case of proprietary NVIDIA drivers.
In all other cases playing with the setting was most likely
harmful as it could result in inconsistent states and the
option not to be honored at all.
This patch resolves this issue by moving the detection whether
to use a direct rendering context completely into the hands of
the set environment variables or the helper program:
* if LIBGL_ALWAYS_INDIRECT is set, we use an indirect context
* if KWIN_DIRECT_GL is set, we use a direct context
* if none of the two are set, we use the helper program, if it
returns 0 we create a direct context, otherwise we set
LIBGL_ALWAYS_INDIRECT and create an indirect context
If a user really wants to influence the behavior the
environment variables can be used.
REVIEW: 102074
Removes the Extension::glxAvailable() from kwinglobals and
implements the functionality in CompositingPrefs, where it
is only needed. There used to be one additional check in
scene_opengl_glx.cpp which is moved into composite.cpp
before the OpenGL Scene is created.
REVIEW: 102002
Also add a usable "doesn't work why" info and WARN! the user about clicking the rearm button.
Merge "OpenGLIsUnsafe" and "CheckIsSafe" config keys
Move the entire checking into CompositingPrefs
BUG:250865
FIXED-IN:4.7
the new GLPlatform class instead.
This change also enables loose binding with the R600 drivers
when DRI2 is being used.
svn path=/trunk/KDE/kdebase/workspace/; revision=1203402
Unknown, unknown just looks bad given that we will have more
nouveau users in future. Neither the vendor, nor the renderer
nor the version string contains a version number. The information
most close to a version number is the gallium number. Other
possible number would be OpenGL version or Mesa version in the
GL version string, but those information is not used in other
Mesa drivers.
svn path=/trunk/KDE/kdebase/workspace/; revision=1184526
'Mesa DRI Intel(R) 965G GEM 20100328 2010Q1 x86/MMX/SSE2',
having one more field from the end - fix reading version
(bnc#605498)
svn path=/trunk/KDE/kdebase/workspace/; revision=1139202
use direct rendering.
- Move the LIBGL_ALWAYS_INDIRECT code to CompositingPrefs::detect(), and use
the external helper program to determine if the variable needs to be set.
svn path=/trunk/KDE/kdebase/workspace/; revision=1096554
to work correctly but as doing it there defeats the purpose of moving
the code to begin with there's no point in moving it.
BUG: 226049
svn path=/trunk/KDE/kdebase/workspace/; revision=1088054
functions and share the value with the KCM; Fallback to XRender
compositing if OpenGL fails to work correctly; Rearrange setting order
in options.h slightly and fix variable names
svn path=/trunk/KDE/kdebase/workspace/; revision=1079919
I've had missing compositing since about a week on my ATI x1300.
After a bit of debugging with the help of fredrikh and mgraesslin, the version string reported seems to be the culprit. I've special-cased the different version string for the R300 driver and it works again now.
The strings my r300 reports are:
DRI R300 Project
Mesa DRI R300 (RV515 7149) 20090101 x86/MMX/SSE2 TCL
1.4 (1.5 Mesa 7.6)
reviewed by fredrikh
kwin people, please have another look, I don't want to break anybody else's setup...
CCMAIL:kwin@kde.org
svn path=/trunk/KDE/kdebase/workspace/; revision=1058156
this rules out GeForce4 and below, but there it's still possible to enable
it explicitly if the user finds it good enough.
svn path=/trunk/KDE/kdebase/workspace/; revision=880710
