Commit graph

14 commits

Author SHA1 Message Date
Vlad Zahorodnii
64ad9a61d8 Introduce ColorManager component
This change introduces a new component - ColorManager that is
responsible for color management stuff.

At the moment, it's very naive. It is useful only for updating gamma
ramps. But in the future, it will be extended with more CMS-related
features.

The ColorManager depends on lcms2 library. This is an optional
dependency. If lcms2 is not installed, the color manager won't be built.

This also fixes the issue where colord and nightcolor overwrite each
other's gamma ramps. With this change, the ColorManager will resolve the
conflict between two.
2020-12-13 23:53:33 +02:00
Vlad Zahorodnii
bdfb946267 Convert Night Color into a plugin
Night Color adjusts the color temperature based on the current time in
your location. It's not a generic color correction module per se.

We need a central component that can be used by both night color and
colord integration to tweak gamma ramps and which will be able to
resolve conflicts between the two. The Night Color manager cannot be
such a thing because of its very specific usecase.

This change converts Night Color into a plugin to prepare some space for
such a component.

The tricky part is that the dbus api of Night Color has "ColorCorrect"
in its name. I'm afraid we cannot do that much about it without breaking
API compatibility.
2020-11-27 18:55:01 +00:00
Vlad Zahorodnii
8f6edea521 Turn krunner integration into a plugin
krunner stuff doesn't really belong in kwin, it has nothing to do with
compositing or any other things that are the domain of compositors.
Given that, being as a plugin suits the krunner integration stuff best.
2020-11-25 09:34:25 +00:00
Vlad Zahorodnii
f037a69f1c Introduce colord integration
This change introduces basic colord integration in wayland session. It
is implemented as a binary plugin.

If an output is connected, the plugin will create the corresponding
colord device using the D-Bus API and start monitoring the device for
changes.

When a colord devices changes, the plugin will read the VCGT tag of the
current ICC color profile and apply it.
2020-11-24 17:51:32 +02:00
Vlad Zahorodnii
c766e5da6d Introduce infrastructure for compositor extensions
The scripting api is not suitable for implementing all features that
should not be implemented in libkwin. For example, the krunner
integration or screencasting are the things that don't belong to be
compiled right into kwin and yet we don't have any other choice.

This change introduces a quick and dirty plugin infrastructure that
can be used to implement things such as colord integration, krunner
integration, etc.
2020-11-24 15:50:33 +00:00
Vlad Zahorodnii
dcf91d4321 Cleanup style in CMakeLists.txt files
We have lots of inconsistency at the moment in CMakeLists.txt files. Most
of it is due to kwin being a very old project. This change hopefully fixes
all of it.
2019-09-17 16:03:05 +03:00
Vlad Zagorodniy
b106579d0f Move package structure plugins to plugins dir
Summary:
Package structure plugins are not that special so move them to
the corresponding directory.

Test Plan: Compiles.

Reviewers: #kwin

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D18685
2019-03-11 10:57:13 +02:00
Martin Flöser
02a0561016 Add windowsystem plugin for KWin's qpa
Summary:
KWindowSystem provides a plugin interface to have platform specific
implementations. So far KWin relied on the implementation in
KWayland-integration repository.

This is something I find unsuited, for the following reasons:
 * any test in KWin for functionality set through the plugin would fail
 * it's not clear what's going on where
 * in worst case some code could deadlock
 * KWin shouldn't use KWindowSystem and only a small subset is allowed
to be used

The last point needs some further explanation. KWin internally does not
and cannot use KWindowSystem. KWindowSystem (especially KWindowInfo) is
exposing information which KWin sets. It's more than weird if KWin asks
KWindowSystem for the state of a window it set itself. On X11 it's just
slow, on Wayland it can result in roundtrips to KWin itself which is
dangerous.

But due to using Plasma components we have a few areas where we use
KWindowSystem. E.g. a Plasma::Dialog sets a window type, the slide in
direction, blur and background contrast. This we want to support and
need to support. Other API elements we do not want, like for examples
the available windows. KWin internal windows either have direct access
to KWin or a scripting interface exposed providing (limited) access -
there is just no need to have this in KWindowSystem.

To make it more clear what KWin supports as API of KWindowSystem for
internal windows this change implements a stripped down version of the
kwayland-integration plugin. The main difference is that it does not use
KWayland at all, but a QWindow internal side channel.

To support this EffectWindow provides an accessor for internalWindow and
the three already mentioned effects are adjusted to read from the
internal QWindow and it's dynamic properties.

This change is a first step for a further refactoring. I plan to split
the internal window out of ShellClient into a dedicated class. I think
there are nowadays too many special cases. If it moves out there is the
question whether we really want to use Wayland for the internal windows
or whether this is just historic ballast (after all we used to use
qwayland for that in the beginning).

As the change could introduce regressions I'm targetting 5.16.

Test Plan:
new test case for window type, manual testing using Alt+Tab
for the effects integration. Sliding popups, blur and contrast worked fine.

Reviewers: #kwin

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D18228
2019-01-27 08:59:58 +01:00
Martin Flöser
054d923411 Move SceneXRender into a plugin
Summary:
First step for loading the compositor Scenes through plugins. The general
idea is that we currently needlessly pull in all the Scenes although only
one will be used.

E.g. on X11 we pull in QPainter, although they are not compatible. On
Wayland we pull in XRender although they are not compatible.

Furthermore our current Scene creation strategy is not really fault
tolerant and can create situations where we don't get a compositor. E.g
on fbdev backend the default settings won't work as it does not support
OpenGL.

Long term I want to tackle those conceptional problems together:
we try to load all plugins supported by the current platform till we have
a scene which works. Thus on Wayland we don't end up in a situation where
we don't have a working compositor because the configuration is bad.

To make this possible the switch statement in the Scene needs to go and
needs to be replaced by a for loop iterating over all the available
scenes on the platform. If we go there it makes sense to replace it
directly with a plugin based approach.

So this is a change which tackles the problem by first introducing the
plugin loading. The xrender based scene (as it's the most simple one)
is moved into a plugin. It is first tried to find a scene plugin and only
if there is none the existing code is used.

Test Plan: Tested all scenes

Reviewers: #kwin, #plasma

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D7232
2017-09-01 17:42:28 +02:00
Martin Gräßlin
e4c333a372 Move clients/ to plugins/kdecorations/
Summary:
KWin's plugins are now all in a plugins subdirectory. This is a good
argument to also move the window decoration plugins there. The name
clients was not really good anyway and makes it difficult for people
not familiar with the code base to find it. Having it under plugins
is the more expectable location.

Reviewers: #plasma

Subscribers: plasma-devel

Projects: #plasma

Differential Revision: https://phabricator.kde.org/D1414
2016-04-15 15:21:03 +02:00
Martin Gräßlin
2bff90976e Move backends/ to plugins/platforms/
Summary:
Source code reorganization:
The base class AbstractBackend got renamed to Platform, thus the
"backends" are "platforms" now. As they are plugins they should go
together with other KWin plugins which are nowadays in the folder
plugins.

So new location is plugins/platforms/

Reviewers: #plasma, sebas

Subscribers: plasma-devel

Projects: #plasma

Differential Revision: https://phabricator.kde.org/D1353
2016-04-12 08:01:27 +02:00
Martin Gräßlin
a8ff9d39a7 Add a plugin for KIdleTime
Basically a simplified fork from kwayland-integration.

We cannot use the idletime plugin from kwayland-integration as it
a) doesn't react on our own qpa plugin name
b) performs blocking roundtrips in the main thread -> freeze

This simplifies by using our internal registry and we don't even check
whether Seat and Idle are announced: we know they are.

Reviewed-By: Bhushan Shah
2015-11-06 13:51:48 +01:00
Martin Gräßlin
26b3569a0b [wayland] Add a QPA plugin for kwin_wayland
This introduces an own QPA plugin for KWin. QtWayland's plugin is not
a good solution for KWin as QtWayland is meant for Wayland clients and
not for a Wayland server. Given that it makes more sense to have a very
minimal QPA plugin which supports the use cases we actually have.

With our own QPA plugin we should be able to improve the following
areas:
* no need to create Wayland server before QApplication
* Qt::BypassWindowManagerHint can be supported
* no workaround for creating OpenGL context in main thread
* sharing OpenGL context with Qt
* OpenGL context for Qt on libhybris backend

The plugin supports so far the following features:
* creating a QPlatformWindow using KWayland::Client (ShellSurface)
* creating a QPlatformBackingStore using a ShmPool
* creating a QPlatformOpenGLContext with Wayland::EGL
* or creating a QPlatformOpenGLContext which shares with KWin's scene
* creating a QPlatformScreen for each KWayland::Client::Output
* QPlatformNativeInterface compatible to QtWayland
2015-08-25 14:33:50 +02:00
Martin Gräßlin
3041a7c32d [wayland] Add a plugin for kglobalaccel
The KGlobalAccelD which gets created by KWin needs a plugin for the
platform specific parts. This change introduces such a plugin. It's
linked against kwin so that it can integrate with the core.

On enable the plugin registers itself in the InputRedirection and
GlobalShortcutsManager checks the plugin whether a shortcut got
triggered.

As the loading of the plugin must happen after InputRedirection is
fully created a dedicated init method is added to InputRedirection.

REVIEW: 124187
2015-07-02 13:42:29 +02:00