This change adjusts the window management abstractions in kwin for the
drm backend providing more than just "desktop" outputs.
Besides that, it has other potential benefits - for example, the
Workspace could start managing allocation of the placeholder output by
itself, thus leading to some simplifications in the drm backend. Another
is that it lets us move wayland code from the drm backend.
The main motivation behind this change is to make the drm backend
multi-purpose. That's it, to make it suitable for implementing all kinds
of compositors. At the moment, there's an artificial split between
"desktop" and "non-desktop" outputs, i.e. VR headsets, which stands in
the way of that and moving the remaining wayland code out of the drm
backend for better layering and architecture.
This way we make sure that we don't explode if for some reason the
surface is destroyed (e.g. it's closed).
This will make it work exactly like the other references to
SurfaceInterface.
BUG: 456817
An effect that implements the "identify" functionality of
the screen configuration kcm. It displays a label on each
screen that identifies the screen.
Doing this as a kwin effect allows to correctly handle
the case when outputs are mirrored (on wayland) compared to
absolute positioning of windows which end up on top of each other.
This allows us to get more information about the outputs like vendor
and model and for example provide them to effects which might find
the extra info useful.
KWin requires surfacesless contexts, so this setSurface() is not needed.
This ensures that makeCurrent() won't make the opengl context current
against a surface that belongs to a removed output.
KWin requires surfacesless contexts, so this setSurface() is not needed.
This ensures that makeCurrent() won't make the opengl context current
against a surface that belongs to a removed output.
The main reason to drop multi-head support is that it has been simply
unmaintained for many many years. When implementing a feature, we don't
even bother checking if multi-head is broken, KCMs don't handle
multihead, window management features are written for Xinerama. KWin
is optimized for Xinerama-like operation mode in general, which is
provided out of the box.
If you use multihead for esoteric gpu stuff, consider using kwin_wayland!
If a DesktopView doesn't handle a keyboard navigation event it
propagates to main which then focusses the next desktop view and the
relevant window.
Empty desktops can also be selected.
BUG: 456068
In WindowHeap we currently always accept the keyboard event regardless
of whether the event was handled.
This will allow the event to propagate to other handlers
In WindowHeap we currently always accept the keyboard event regardless
of whether the event was handled.
This will allow the event to propagate to other handlers
Most xwayland clients don't know their desktop file name, so use the
StartupWMClass field in their desktop files as means to inferring their
desktop file name.
BUG: 455265
We assume that outputs in kwinApp()->platform()->enabledOutputs() are
stored in the xinerama order. However, this is not the case on Wayland
and it's not going to be changed because it increases the complexity.
This change makes Workspace::xineramaIndexToOutput() use Xinerama
extension API to map a xinerama index to the associated Output object.
With this, Xwayland applications will be able to put on outputs as
expected.
Note that xinerama indices are not cached because
Workspace::xineramaIndexToOutput() is not used in any hot code path. If
that changes, xinerama indices can be cached. The cache must be
invalidated whenever we get screens changed notify event from RANDR.
Currently, we implicitly assume that enabled outputs are stored in the
xinerama order, but with ongoing refactorings, it's easy to break that
assumption. Also, we are not going to change the DRM backend so it
stores enabled outputs in the xinerama order.
This change adds xinerama index conversion helpers in order to reduce
the number of potential regressions with output refactorings.
There was a geometry change that fixed mixing the next and current
geometries. While it did fix issues on wayland, it broke window shading
on x11 because of an obscure resize() call.
That obscure resize() had a side-effect that ensures m_clientGeometry
has the right value so the next time the window is unshaded,
implicitSize() will return a good value.
In order to make window size computation more robust, this change makes
X11Window compute the natural frame size based on cached size in
m_client, which shouldn't change when the window is shaded.
However, given how buggy window shading is and how difficult it is to
make it work right, I think that it's better to deprecate window shading
and remove it in some future release.
BUG: 450582
