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.
Don't fall back into other composition systems if KWIN_COMPOSE is
explicitly set. In such case, just exit().
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Alpha from clients is encoded in electrical values, and some of our code also relies
on compositing results being encoded in electrical values. To take care of this, we
need to undo the premultiplication of rgb values, convert to or from linear, and then
re-do the premultiplication. This doesn't result in exactly the same blending behavior
with linear blending, but it's close enough
Now that decoration configs are separate plugins we can plug those into KCMultiDialog instead of hand-rolling it ourselves
As a nice side-effect this should allow to implement the decoration config in QML
BUG: 470902
The test is flaky. We work around it by passing --repeat until-pass, but
lately even it doesn't help us with this issue.
So skip the test when running it inside KDE CI for a few months until
it gets a newer kernel.
It makes decorations lighter as they don't need to bundle its
configuration logic.
Deprecates the kcmodule property in favour of kcmoduleName which instead
of assuming that the kcm is local to the plugin, it provides the plugin
name to find and load.
It appears PyCharm can change WM_HINTS propery of override-redirect
windows when they are closed, which triggers a crash in kwin.
This change adds the corresponding guard. In addition to the icons, it
adds a few more guards to prevent kwin crashing when a rogue client sets
wrong properties on an override redirect window.
BUG: 470874
Floating point arithmetic and/or the use of GL_LINEAR in the pipeline,
may result in visual glitches due to rounding (errors). As a short-term
fix until a proper (more involved) solution is in place for Plasma 6,
pad the damage slightly in all directions to alleviate those effects.
The main motivation for the rewrite is to properly port ShmClientBuffer
to our GraphicsBuffer abstractions. As is, libwayland implementation is
not suitable for our needs. We may need ShmClientBuffer to be alive when
its corresponding wl_shm_buffer resource is destroyed, for example to
play a window closing animation. With the existing api, we need to fight
libwayland. Besides that, libwayland doesn't provide a way to get
underlying pool file descriptor, which is needed to fill ShmAttributes.
