Summary: D8479 fixes viewport for real hardware, but there is still problem with screenshots. This patch fixes that.
Test Plan:
- Have three monitors (like in bug 385655)
- Press PrtSc and then Enter
- Screenshot is ok
Before:
{F5450056}
After:
{F5450058}
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8485
Summary:
glScissor works on window co-ordinates. i.e not scaled by the viewport
We need to multiply by the scale there.
This fixes a minor visual glitch in animations when using hardware
clipping.
Test Plan:
Hardcoded my minimise animation to be really slow.
Now every frame looks perfect
Reviewers: #kwin
Subscribers: kpiwowarski, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8490
Summary:
The GL_CONTEXT_LOST flag is not reset when calling glGetError. This of
course bites with: "Thus, glGetError should always be called in a loop,
until it returns GL_NO_ERROR, if all error flags are to be reset."
(see https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetError.xhtml)
As KWin calls checkGLError from init call it can result in a freeze of
KWin. This is a regression reported multiple times since the release of
5.10.3 which enabled GLX_NV_robustness_video_memory_purge extension.
Please note that I am not able to test this change. I do not have an
NVIDIA card and are not hiting the problem. I have no way to simulate
the code. I do not know whether the change will fix the problem, it is
based on what others do. Inspiration for this change is mostly from
mutter: https://git.gnome.org/browse/mutter/commit/?id=d4d2bf0f6c1737256b921c4f1dedd3a95138cab9
BUG: 381870
FIXED-IN: 5.10.3.1
Test Plan: See above, I can only compile check the change
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6464
Summary:
We are getting reports about the shader self test failing in a false
positive way on Mesa 17. We already have such false positve results
for NVIDIA quadro and went with disabling the self test.
Most likely our self test has a problem or the rendering of the first
frame has a problem. But disabling compositing because our rendering of
the first frame is broken, is too much.
Let's better be pro user here and disable the shader self test till we
fixed the root problem.
BUG: 376801
FIXED-IN: 5.10.4
Test Plan: It compiles.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6426
Summary:
The backend is responsible for setting the viewport, the GLRenderTarget
should save and restore the viewport actually set by the backend.
Test Plan:
Ran Blur effect which uses this method, under scaling the viewport "restored"
differed from the one set by the backend.
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4952
Summary:
This method already translates to s_virtualScreenGeometry as the source
co-ordinates are in compostior space we should take scaling into account here too.
This method already supports resizing if source and target sizes do not match.
Calling funcitons can either double the size of the target if they want native resolution
or leave as-is if they want the result in standard DPI.
This implements scaling in the screenshot, magnifier and simple blur effect.
Test Plan:
Tested screenshot effect using spectacle.
I hit an (unrelated, was reproducible on master) crash whilst using this, so it is not fully tested
Ran magnifier effect manually
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4951
Summary:
GLRenderTarget already stores the translation from global compositor
space to the render target co-ordinates, we also need a scale factor for
the exact same reasons.
Test Plan: Used in various effects after this patch and it works there.
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D4948
Summary:
The feature has always been considered experimental. Unfortunately it is
completely unmaintained and hasn't seen any commits in years. It
requires kolor-manager to function, but that has not seen a release
based on frameworks yet. This makes it difficult to maintain. In fact I
have never been able from the introduction till now to setup a color
corrected system. One needs kolor-manager and oyranos and especially the
latter is hardly available on any linux distribution (e.g. not on the
Debian/Ubuntu systems).
Due to being unmaintained color correction in KWin did not keep up with
recent changes. Neither did it see any updates during the xlib->xcb
port, nor during the Wayland port. Especially the Wayland port with the
rendering changes make it unlikely to function correctly. E.g. Wayland
introduced a proper per-screen rendering, while color correction did a
"fake" per screen rendering. How that is going to work in combination is
something nobody ever tried. Now after the introduction of proper
per-screen rendering the solution would be to port color correction to
the new api, but that never happened.
Color correction also modified the shaders, but a newer shader API got
introduced some time ago. Whether the color correction shader support
that or not, is unknown to me. Also which shader language versions are
supported. I know it was based on 3d texture support, which back on
introduction was partially lacking in OpenGL ES. Nowadays that changed,
but color correction didn't update.
Last but not least it is completely X11 based and there is no work on
how to make it work with Wayland.
Given all the problems, especially the fact that it is unmaintained and
cannot be setup on my system, means to me that the only solution is to
remove it.
I'm open to having it reintroduced in future, but only if the
availability on Linux distributions gets addressed before. As long as
major linux distributions do not ship this feature, it should not be in
KWin. Given that I must say that it was a mistake to add it in the first
place and I need to point out that I was against the merge back then.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3402
Summary:
Not used anywhere in KWin and annotated that they should be removed. As
we have an ABI break in 5.9 we can remove them now.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3398
Summary:
Instead of having the egl extensions in the global kwinglutils lib it
becomes private to the AbstractEglBackend. Just like on glx the
glxextensions are moved into the platform.
The extensions are queried from initEglAPI, that is as early as possible
after initializing the EGLDisplay. This ensures that any implementing
subclass can access the extensions early enough.
As a note: the EglOnXBackend had a potentially wrong sequence for
initializing the buffer age extension. It is now moved to the correct
place where the result is needed for the first time.
From the global API eglExtensions are removed from hasGLExtension and
the eglExtensions function is dropped. As by that initEGL did not do
anything it is also dropped.
Test Plan:
Tested nested kwin on Wayland, still works, extensions shown
in debug console
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3396
Summary:
Method doesn't do anything. If at some point we want to resolve egl
functions again, it should be done in the Platform, just like
glxResolveFunctions is nowadays done in the platform.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3391
Summary:
It's unused in KWin and absolutely not needed as the call to
eglInitialize, which every platform does, also gives the version for
free. So no need to do any caching in a global method.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3390
Summary:
KWin still resolves some OpenGL function pointers. For that it needs to
use either eglGetProcAddress or glxGetProcAddress. With other words the
method to resolve needs to know whether it is egl or glx and needs both
a dependency to egl and glx. Especially the dependency to glx is ugly as
that pulls in XLib into our library.
The way so far was to pass an enum value to the initGL method to know
whether it's EGL or GLX. With this change the enum value is removed and
replaced by a function pointer to resolve the methods.
This simplifies the resolve code and allows to completely remove the glx
variant we still had in the library. Thus kwinglutils library is now glx
and XLib free.
Test Plan: nested KWin with OpenGL/EGL still works
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3336
Summary:
No need to resolve glx methods through the shared lib. At the moment
this duplicates some code, but will be cleaned up with a follow up
change.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3335
Summary:
Glx extensions are only interesting to the glxbackend. Given that
querying can be moved there.
In order to simplify the extensions can be stored in the OpenGLBackend
which also provides the convenience check as before.
The egl platforms should also be adjusted to query in that way and
remove it from the kwinglutils.
There is still a usage of the glxextensions inside kwinglutils to
resolve one function. That should also be moved into the platform.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3332
Summary:
Glx version is only required once in the standalone x11 platform. No
need to have that in the shared kwinglutils library.
Removes one xlib usage from shared kwin.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3329
Summary:
The viewport needs adjustment in the per-output rendering case. This
change ensures the viewport is setup like in the platforms which do per
output rendering. For the X11 case (multiple outputs in one render pass)
the values are the same as previously.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3099
Summary:
This is similar to ff6e042c7f just for
GLRenderTarget instead of GLVertexBuffer. The reasoning is the same: on
Wayland KWin has one native window per screen and needs to adjust the
blit target depending on the area.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3056
Summary:
On Wayland in multi-screen a "window" is used to render to per screen.
In OpenGL every "window" is at 0/0 and scissoring is in respect to the
window geometry. The rendering geometry passed to VBO rendering, which
performs the scissoring, is in virtual combined screen geometry space.
Thus the scissoring always removes any rendering on the second screen.
This results in e.g. wobbly windows not working on any additional screen
on Wayland.
This change makes the VBO rendering multi-screen aware by passing the
current virtual window geometry in each rendering pass. That replaces
the so far used virtual screen size. For single screen rendering or
multi-screen rendering on X11 this doesn't change anything as there is
always only one OpenGL window and the screen geoemetry starts at 0/0.
Thus the subtracting of x/y geometry do not affect the scissoring at
all.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2955
Summary:
The self test fails with NVDIDA 370.23 or newer on Quadro hardware.
Most likely there is a bug in our code as the same things work later on.
But without the hardware we are not able to reproduce and investigate
properly. Given that all we currently can do is to skip the self test.
We encourage users to investigate this properly and to help us to
identify the root issue, so that we can fix it.
CCBUG: 367766
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2744
Summary: No need to parse the OpenGL version twice with different algorithms.
Reviewers: #kwin, bshah
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2414
Summary:
The new tab shows the information from GLPlatform similar to how it is
shown in the supportInformation. In addition it also lists all available
openGL and EGL/GLX extensions. For that kwinglutils is extended by
functions to return the lists of extensions.
Reviewers: #kwin, #plasma, bshah
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2385
The idea was to block shaders that operate on
Texture2D while Texture2DRectangle was use, but
that's indeed controlled by TextureNPOT while
LimitedNPOT indicates Texture2D but without support
for mipmapping and exotic clamping
FIXED-IN: 5.6
REVIEW: 126959
One resource is used for shader version 1.10 and one for version 1.40.
The ideas behind this change is to remove the locating of the shader
sources and also to fix that user provided shaders could be loaded
instead of the original ones (possible attack vector on Wayland).
To simplify the ShaderManager provides a new method call to load the
shader from the resource. This means the effects don't need to
duplicate the check for the shader version any more and also don't
need to duplicate the file reading functionality.
REVIEW: 126905
This method allows to generate a shader with ShaderTraits but one
part (e.g. vertex and/or fragment) to be replaced by custom shader
code.
Thus it can be used as a replacement for the load*(ShaderType) variants
and allows more effects to transition to shaders using traits.
The way nearestPowerOfTwo is currently defined allows for the possibility of
left-shifting an int by 32 bits or more, which is undefined behavior on
platforms where int is 32 bits, and is something that can happen here if `s`
is equal to 31 by the end of the loop. Noted by Coverity as CID 1291191.
This patch takes an algorithm to perform the same operation from Hank Warren
Jr.'s book "Hacker's Delight", which should avoid UB.
REVIEW:126540
For the functions from GL_FOO_robustness we want to resolve it by
ourselves in order to add a custom implementation if it's not available.
Unfortunately once epoxy.h is included this breaks as epoxy defines the
names and so through the preprocessor epoxy always wins.
So we need different names: all functions from robustness get a "kwin"
prefix and the usage is changed everywhere in kwin source code.
REVIEW: 125883
-use qstringliteral only when necessary (i.e. not in concat or comparison)
-use qbytearray instead of qstring when dealing with latin1 input and output (glplatform)
-use qstringref to extract numbers from strings (glplatform)
-define qt_use_qstringbuilder to optimize all string concatenations
-anidata: use ctor init lists, add windowType member initialization
REVIEW: 125933
So far it was bound to whether we build for GLES. But this is
semantically wrong. It might be possible that even on desktop gl
epoxy is built without GLX support, thus we need to reflect this.
This change ensures that epoxy/glx.h is only included if available,
that relevant code is bound to it and that checks are in place to
enforce EGL if not build with glx support.
In addtion the glxbackend.cpp is now only included in the build set
if available.
Only those which truly are different are kept as compile time checks.
In addition the index buffer is made available to GLES as in principle
all required functionality is available on gles.
REVIEW: 125865
It doesn't make much sense any more as we do no longer link EGL since the
switch to epoxy. And epoxy pulls it in at runtime if needed.
Even more on Wayland it's just plain stupid to have EGL disabled. So
removing the option just simplifies our code base without any
disadvantages.
REVIEW: 124695
The glVersion was not set at all for gles causing any code doing a
hasGLVersion check to fail which means that the compositor doesn't
start at all, because it has a hasGLVersion(2, 0) check.
The complete ifdef is no longer needed. The used additional glGetStringi
is also available in gles 3.0, thus epoxy can handle it quite well
without a need for ifdef.
Unfortunately the version string can be "strange" on GLES. On desktop
it looks like: "3.0 some driver foo", on GLES it could also be:
"OpenGL ES 3.0 some driver bar". Thus to make the logic work we are
first removing any leading "OpenGL ES " and hope that then the version
is encoded just like on GL.
