Commit Graph

8 Commits (1fb2eace3fbfc6645e024aa0f5003306ac60a417)

Author SHA1 Message Date
Martin Gräßlin 17e0bad922 Drop OpenGL based color correction from KWin
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
2016-11-22 07:16:51 +01:00
Martin Gräßlin 853020336f Introduce a config option whether applications are allowed to block compositing
Summary:
From feedback we got it seems that not all users agree to games and
other applications blocking compositing. Some users prefer to have
compositing always on even if this gives a small performance penelity.

This change introduces a dedicated config option to specify whether games
are allowed to block compositing. By default this option is enabled.

The setting can be overwritten with a window specific rule. So usecases
like all windows except this very specific one are supported.

In the user interface the config option is shown where previously the
unredirect fullscreen option was shown.

Test Plan:
Run a game which should block compositing, verified it blocks.
Changed the setting, run the game again, verified it doesn't block. And
once more for with allowing to block.

Reviewers: #kwin, #plasma_on_wayland, #vdg

Subscribers: plasma-devel, kwin

Tags: #plasma_on_wayland, #kwin

Differential Revision: https://phabricator.kde.org/D2584
2016-09-13 15:47:05 +02:00
Martin Gräßlin 996ee34e14 Remove the unredirect fullscreen windows functionality
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.

Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.

By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.

It's clearly something we tried to hide from the user that it exists.

For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.

Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.

Reviewers: #kwin, #plasma, #vdg

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D2180
2016-08-04 14:48:35 +02:00
Martin Gräßlin d52944c2c7 [kcmkwin/compositing] Remove combobox to select between GLX and EGL
Summary:
The selection of whether GLX or EGL should be used doesn't work in
practice due to the following reasons:
* Intel/EGL/X11 results in rendering errors
* NVIDIA still doesn't support EGL
* OpenGLES forces to EGL (combobox only one entry)
* Wayland forces to EGL (combobox only one entry)

Offering the selection only offers the user a way to destroy the
system. We get too many bug reports about rendering errors and we
get too many complaints about this not working properly on social
media. E.g.: "The Meh: EGL mode causes bugs in the launcher"

The configuration interface showed a warning when selecting it, but
apparently users ignore warnings like "might be broken". If that's the
case let's better remove the option.

If users really want this they can still enable it manually through
editing the config file or through the env variable.

Change intended for Plasma/5.7 branch - I'm sick of users complaining
about it!

Test Plan: Opened KCM, verified Combobox is gone

Reviewers: #kwin, #plasma, #vdg

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D2224
2016-07-19 17:10:24 +02:00
Martin Gräßlin 04d6bd2874 [kcmkwin/compositing] Fix ordering of items in keep window thumbnail combo box
BUG: 343399
FIXED-IN: 5.2.1
REVIEW: 122424
2015-02-04 14:05:16 +01:00
Pino Toscano 1884798991 fixuifiles 2014-11-20 08:04:54 +01:00
Martin Gräßlin 58668e52a0 [kcmkwin/compositing] Show warning message when selecting "dangerous" options
The idea is to warn the user that changing the settings might break
the setup when we know it could be dangerous. The following cases are
considered:
* Scale filter Accurate
* Tearing prevention
* keep window thumbnail always
* EGL if EGL and GLX are available
* unredirect fullscreen not working on all hardware

In addition the OpenGL is Unsafe warning is turned int a KMessageWidget
which is also used for all the other warnings.

REVIEW: 118494
2014-06-16 09:04:33 +02:00
Martin Gräßlin c16472e535 [kcmkwin/compositing] Use a classic ui file for the Compositor settings
For a classic user interface like the advanced compositor settings the
good old widgets are still better suited than the new QuickControls.

REVIEW: 118273
2014-06-02 14:58:00 +02:00