Currently, there's a separate pass to filter out windows not ready for
compositing or windows that must be invisible. That has two issues: we
could merge that pass with the pass that populates stacking_order and
"windows" can detach.
libinput_device_get_user_data() can be used to get the associated Device
object with libinput_device. That way, we won't need to maintain a
private list of all input devices.
If the window filter rejects a window, that window won't be in the
stacking_order and henceforth won't be painted, so finalDrawWindow()
does extra work of checking again if the window is accepted.
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.
