Adds a test that has two windows and one activates the other.
There are two versions: qt5 and qt6.
The Qt 6 code is vastly different since Qt 6 knows about
xdg_activation_v1, so it makes sense to have both for now.
Effects may perform cleanup when a deleted window is removed. If that
happens and the SceneWindow is accessed, kwin may crash.
The Scene processes Workspace::deletedRemoved() before effects.
In order to fix dereferencing null pointer, this change makes the Window
destroy its associated SceneWindow.
Format modifiers enable the graphics hardware to be much more efficient,
especially when it comes to multi-gpu transfers. With the issues regarding
bandwidth limits now solved, enable them by default to make all supported
systems benefit from them.
CCBUG: 452397
CCBUG: 452219
When explicit modifiers are used, it can happen that Mesa chooses modifiers that make
the display hardware hit bandwidth limits. In that case, atomic tests fail and the
outputs don't work, or KWin may even crash.
In order to work around that, DrmGpu now removes the used modifier whenever an atomic
test fails, and tries to find a working combination of outputs and modifiers.
If a window is destroyed before the frame is presented, the window
pointer will be dangling.
In order to make kwin handle that case correctly, the window is captured
using a QPointer.
While having all state be public is great for avoiding the boilerplate that
comes with setters and getters, it also exposes more state than necessary
to the rest of the backend and makes it more error-prone if more than one
part of the state needs to be changed at the same time.
WindowThumbnailItem doesn't depend on features that are available only
with managed window.
By making WindowThumbnailItem work with all kinds of windows, its code
is easier to work with and refactor.
Instead of passing all possible field values to the initialize()
function, pass all relevant data in a struct. With designated
initializers, it's more readable and makes code more comprehensible.
The general goal is to split Output's data in two categories - general
information about the output (e.g. edid) and mutable state (position,
mode, etc).
With this, the drm backend will be able to associate drmModeModeInfo
with Output's modes, which can be useful if there are several modes with
the same resolution and refresh rate but different flags.
Aleix Pol