This makes KWin switch to in-tree copy of KWaylandServer codebase.
KWaylandServer namespace has been left as is. It will be addressed later
by renaming classes in order to fit in the KWin namespace.
Instead of creating a gammaramp object with a fixed size, make the color
device create a color transformation object that can be used to construct
arbitrary LUTs. This is needed in order to support tiled displays well
and is useful for further color management work.
When we do more color management stuff we'll need it in more places,
making it a hard requirement reduces the amount of needed ifdefs and
should make adding color management features a little simpler.
AbstractOutput is not so Abstract and it's common to avoid the word
"Abstract" in class names as it doesn't contribute any new information.
It also significantly reduces the line width in some places.
The main motivation behind this change is to unify render target
representation across opengl and software renderers and avoid accessing
the render backend directory in order to get the render target.
Notifications are really only useful in a setting with a full
shell environment where there is a notification center to display them.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Software cursor has always been a major source of problems. Hopefully,
porting it to RenderLayer will help us with that.
Note that the cursor layer is currently visible only when using software
cursor, however it will be changed once the Compositor can allocate
a real hardware cursor plane.
Currently, software cursor uses graphics-specific APIs (OpenGL and
QPainter) to paint itself. That will be changed in the future when
rendering parts are extracted from the Scene in a reusable helper.
This is the first tiny step towards the layer-based compositing in kwin.
The RenderLayer represents a layer with some contents. The actual
contents is represented by the RenderLayerDelegate class.
Currently, the RenderLayer is just a simple class responsible for
geometry, and repaints, but it will grow in the future. For example,
render layers need to form a tree.
The next (missing) biggest component in the layer-based compositing are
output layers. When output layers are added, each render layer would
have an output layer assigned to it or have its output layer inherited
from the parent.
The render layer tree wouldn't be affected by changes to the output
layer tree so transition between software and hardware cursors can be
seamless.
The next big milestone will be to try to port some of existing kwin
functionality to the RenderLayer, e.g. software cursor or screen edges.
It's not practical, regular users don't care about window geometry. One
could argue that it can be useful for creating window rules, but window
rules kcm pulls relevant properties from kwin.
If needed, one can reimplement this feature as a QtQuick script that creates
an overlay window positioned above the window that is being interactively
moved or resized.
While a stylus is in proximity we want to show its cursor. In this commit
it only gets shown on move because for a still unknown reason the position
is out of date before the first move event.
BUG: 443921
The main idea behind the render backend is to decouple low level bits
from scenes. The end goal is to make the render backend provide render
targets where the scene can render.
Design-wise, such a split is more flexible than the current state, for
example we could start experimenting with using qtquick (assuming that
the legacy scene is properly encapsulated) or creating multiple scenes,
for example for each output layer, etc.
So far, the RenderBackend class only contains one getter, more stuff will
be moved from the Scene as it makes sense.
Hardware constraints limit the number of crtcs and which connector + crtc
combinations can work together. The current code is searching for working
combinations when a hotplug happens but that's not enough, it also needs
to happen when the user enables or disables outputs and when modesets are
done, and the configuration change needs to be applied with a single atomic
commit.
This commit removes the hard dependency of DrmPipeline on crtcs by moving
the pending state of outputs from the drm objects to DrmPipeline itself,
which ensures that it's independent from the set of drm objects currently
used. It also changes requests from KScreen to be applied truly atomically.
The main motivation behind this change is to prepare input abstractions
for virtual input devices so the wl_seat can properly advertise caps or
the cursor getting properly mapped/unmapped when a fake pointer is
added/removed on a system without a hardware mouse connected.
With this, there are three abstractions - InputDevice, InputBackend, and
InputRedirection.
An InputDevice represents an input device such as a mouse, a keyboard, a
tablet, etc. The InputBackend class notifies the InputRedirection about
(dis-)connected devices. The InputRedirection manages the input devices.
Such design allows to unify the event flow for real and virtual input
devices.
There can be several input backends active. For example, the libinput
backend and an input backend that provides virtual input devices, e.g.
libeis or org_kde_kwin_fake_input.
This can be useful for QML scripts that deal with virtual desktops.
The virtual desktop model keeps a copy of virtual desktop objects to
avoid hitting asserts in QAbstractItemModel (it has some asserts to
ensure that indices passed to beginInsertRows() or beginRemoveRows()
make sense).
The main motivation behind this change is to prepare kwin for importing
kwayland-server code in libkwin.
As is, builtin effects are linked with libkwin. Some builtin effects
have wayland specific code. If we move wayland stuff in libkwin, there's
going to be a circular dependency between kwin4_effect_builtins and
libkwin targets.
This change intends to break that dependency by linking builtin effects
to kwin executable.
The main issue with that is that EffectLoader would need to discover the
effects indirectly. QStaticPlugin is used for that purpose.
Besides breaking the cyclic dependency, it makes builtin effects use the
same plugin infrastructure in libkwineffects that external effects use.
Metadata in src/effects/effect_builtins.cpp was converted in a list of
python dictionaries, which was fed to a python script that generated
main.cpp and metadata.json files.
Startup code in plasmashell was changed so xsetroot is not called
anymore, which is sort of fine.
Unfortunately (or not?), it exposed a bug in kwin. Cursor::x11Cursor()
only works in the standalone X11 session.
On Wayland, Cursor::x11Cursor() will return XCB_NONE which results in
seeing cross cursor when there should be arrow cursor.
This change moves xcb_cursor_t look up code from X11Cursor to the base
Cursor class. In hindsight, I would like to introduce a window manager
class where the xcb cursor and other x11 specific code can be moved in
the future for better encapsulation of platform-specific code.
CCBUG: 442539
This way if kwin_wayland crashes we don't need to ensure that new
environment variables need to get synced across the new env.
This fixes an issue where spawning an xwayland application from a
wayland window that survives a crash would fail.
By moving the logic here we no longer need to wait for kwin_wayland to
start before starting plasmashell or even ksmserver as all environment
variables are set. As long as the wrapper is ready we can continue
starting and clients will just block on connect.
That should still allow for both a lot of optimisations both for speed
and cleaning up the startplasma-wayland scripts.
This will be addressed in follow up patches.
Use of kwin_wayland directly with xwayland is still supported for
testing.
Currently, thumbnail items are rendered by kwin. This means that qtquick
code cannot do things such as applying shader effects to window thumbnails
or simply draw custom controls on top of thumbnails.
With this change, task switchers and qml extensions will be able to
place their own contents on top of thumbnails and apply custom effects
to them.
In order to integrate window thumbnails, a window is rendered on kwin
side using its own opengl context. A fence is inserted in the command
stream to ensure that the qtquick machinery doesn't start using the
offscreen texture while there are still rendering commands being executed.
Thumbnails are rendered into offscreen textures as we don't have full
control over when qtquick windows render their contents and to work around
the fact that things such as VAOs can't be shared across OpenGL contexts.
WindowThumbnailItem and DesktopThumbnailItem act as texture providers.
