Static plugins being linked with shared libraries doesn't work smoothly.
POSITION_INDEPENDENT_CODE target property needs to be set for
every such plugin. However, there can be targets that we have no control
over, which need POSITION_INDEPENDENT_CODE to be set too. Asking such
projects to add this property and them refusing to do so would be
reasonable because kwin's entire static plugin pipeline is weird.
The test framework was made a shared library because kwin build
directory used to get really big (in 10s of gigabytes).
Due to the -fPIC issues, this change makes the test framework a static
lib again. Obviously, this brings back the big build directory problem.
But, it's not as terrible as it used to be. With this change, kwin build
directory is a couple of gigabytes in debug build, which is a lot but
not as bad as it used to be before.
Window captions have a suffix for disambiguation, based on window
captions of other mapped windows.
In xdgshell we update this when a caption changes, but this could be
before a window is mapped. This can lead to two windows at once having
the same suffix, as a suffix could be used but not in the list of
searched clients.
BUG: 450369
Outputs get disabled before they get destroyed, so destroying the window
when the output gets disabled and when it gets destroyed causes the window
to be destroyed twice and run into an assert
The InputConfig was introduced to handle tests that don't have valid
kwinApp object. Those tests have been either reworked or dropped, so
let's drop the InputConfig to tidy the config stuff.
Interactions with KScreen cause settings to be reset to the default when the lid
gets closed, so handling lid closing in KWin needs to wait until KScreen no longer
writes configs
BUG: 471282
This allows us to avoid losing precision when updating surface pixmaps.
Surface damage needs special handling either way.
Another advantage from switching to buffer damage is that it lets us to
decouple surface textures from surface items, which is useful for making
surface helpers more reusable.
Because the kcm list has to be maintained manually, it's prone to get
outdated and incomplete (it already is!). On the other hand, "configure
window manager" is somewhat redundant as same kcms can be opened in
system settings.
If a gbm_bo is allocated with GBM_BO_USE_WRITE, it will be backed by a
dumb buffer under the hood. However, it seems like neither gbm_bo_get_fd()
nor gbm_bo_get_plane_fd() would return valid file descriptors, which are
required to fill in DmaBufAttributes.
As an interim solution, this change makes the GbmGraphicsBufferAllocator
allocate dumb buffers on its own rather than delegate it to gbm.
The egl import mode ensures that there's a local buffer, which is
preferred as it minimizes the number of data transfers over PCIe.
With dmabuf, it's unclear what the driver will do. But the main takeaway
from discussion with mesa developers is that it's undesired for
gbm_bo_import() to migrate or perform data transfers behind the user's
back, it should be done explicitly.
This change ports the drm backend to the GraphicsBuffer and
GraphicsBufferAllocator.
The main motivation is to unify graphics buffer abstractions across
various backends and to prepare it for output layers, which could be
nicer if we could have direct control over the buffers.
GEM handles are not reference counted and are unique per drm file
descriptor.
With the upcoming changes, dmabuf and dumb buffers will be abstraced
using DmaBufAttributes.
The issue with it is that we need GEM handles to get a drm framebuffer.
drmPrimeFDToHandle() can be used to get the GEM handle for a drm file
descriptor, but we would hit the reference counting issues then and
potentially double close GEM handles.
In order to resolve that, this change makes the drm backend reopen the
drm node to get a new GEM handle namespace for rendering.
The drm backend needs to allocate both dmabuf and dumb buffers, for
example for multi-gpu import.
Allowing GbmGraphicsBufferAllocator to allocate dumb buffers allows us
to avoid using several buffer allocators in the drm backend.
The software flag indicates whether the graphics buffer allocator needs
to allocate a buffer suitable for software rendering. Its intended usage
is to allow the gbm allocator to allocate both dmabuf and dumb buffers.
When we delete a window we unredirect, when we unredirect, we delete the
framebuffer which requires an openGL context.
handleWindowDeleted is the entry point from workspace events to effects
code, so it's made current here.
BUG: 444665
BUG: 471139
We were binding to the statusChanged signal, but then only doing
anything if the status had changed to "Activating". This did not work
for when the effect was activated without a gesture, because then its
status would change straight to "Activated", bypassing the in-between
state of "Activating."
This fixes clearing the search text on activation without a gesture.
This change makes the EffectsHandler emit the windowAdded signal as soon
as the Workspace::windowAdded signal is received and minimize the
difference between the states observed in kwin core and effects.
This will ensure that the window animation is advanced only if the
window is painted. I'd like to rely on this to allow effects schedule
animations as soon as Workspace::windowAdded signal is emitted.
As is, the issue with delaying EffectsHandler::windowAdded is that we
don't filter out all "not ready" windows, which breaks some effects
because EffectWindows are leaked in some properties but no
EffectsHandler::windowRemoved signal is emitted so those effects can
perform cleanup. Fixing that by the means of ensuring that only renderable
EffectWindows are exposed is hard too, and it would also mean that
effects need to use their own api, which I would like to avoid and port
the effects to kwin core apis instead.
