Instead of an external service (like KScreen) storing and restoring output configurations,
with this commit KWin takes over that responsibility. This allows it to, among other things,
generate appropriate configs for new sets of outputs immediately, and take KWin-internal information
about outputs into account when generating them.
CCBUG: 474021
CCBUG: 469653
CCBUG: 466342
CCBUG: 470863
CCBUG: 466556
BUG: 466208
BUG: 455082
BUG: 457430
This is useful for the few cases where wheel events are not for
scrolling. For example adjusting the volume in the tray.
In this case having the metadata that the delta is backwards is
important. From a kwin POV it's just proxying the libinput
isNaturalScroll setting to clients.
Tested against "qtbase/examples/widgets/widgets/mousebuttons" with
modified Qt and changing the setting in the UI.
Not mergable until upstream lands.
Relevant link:
https://gitlab.freedesktop.org/whot/wayland/-/merge_requests/1 /
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/183
CCBUG: 442789
Transactions provide a way to apply new surface state to multiple
surfaces atomically.
A transaction can be locked. In which case, it's not going to be applied
until all locks are dropped. For example, this can be used to delay
applying new surface state until the committed buffers become idle.
Currently when we move the mouse the one render loop triggers a repaint.
When the cursor layer needs a new update we end up in the compositor
repainting the main content.
Even though painting should mostly no-op it still goes through all
existing items and effects to collect damage, still potentially making
the GL context current which could stall. A waste when we know we
haven't got anything to do. It's enough to cause noticable mouse lag on
some hardware.
Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
It never belonged in the OutputBackend, but we also didn't have a better
place when the relevant code had been added.
With the introduction of graphics buffer allocators, it's no longer the
case.
The buffer transform specifies a transform from the buffer coordinate
space to the surface coordinate space.
The inverse buffer transform specifies a transform from the surface
coordinate space to the buffer coordinate space.
OutputTransform::map(QRect, QSizeF) expects both arguments to be in the
same coordinate space.
In case of SurfaceInterfacePrivate::computeSourceBox(), both should be
scaled surface coordinates so bufferTransform.inverted() maps the source
rect to the proper buffer coordinate space.
Instead of hardcoding ARGB8888 and using implicit modifiers, look through
the list of available formats and modifiers and pick a match that egl will
actually accept.
In some cases, it's desired to know what the inverse transform of a
given output transform is. It's possible to make it work by providing
helper functions, but we tend to avoid doing so.
This change converts the OutputTransform from an enum to a class so it's
possible to have both data + methods in the same type. Unfortunately,
unlike Rust, C++ provides no way to attach methods to enums, classes and
structs is the only way to go.
Being in the KWin namespace has a couple of advantages: the enum can be
forward declared, and the transform can be replaced with a slightly more
complex but useful type.
If the surface item's contents is scaled, i.e. its scale factor doesn't
match the output's scale, GL_LINEAR will be applied to smooth the
contents. The unfortunate thing is that it's possible some of the
changed pixels will bleed to the neighbor ones.
In order to handle that scenario better, this change makes the
SurfaceItem expand the damage if there's scale factor mismatch.
bufferSourceBox and bufferTransform properties were introduced to detect
if the surface contents is going to be scaled. bufferSourceBox covers
both crop transform from wp_viewport and scale factor from wl_surface.
bufferTransform is same as wl_surface's buffer transform property.
The bufferSourceBox provides a way to get the source region of the
attached buffer. It can be used to compute the effective scale factor
when using wp_viewport.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
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.
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.
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.
This is done by converting from the sRGB + gamma 2.2 input from clients
to linear with the color space of the output (BT.709 or BT2020 atm) in
a shadow buffer, and then convert from the shadow buffer to the transfer
function the output needs (sRGB or PQ).
When GraphicsBuffer::dropped() is emitted, the buffer can be
unreferenced. If that's the case, the GraphicsBuffer will be deleted
twice: first in GraphicsBuffer::unref(), the second time in drop().
In order to address the issue, this change gets rid of the
GraphicsBuffer::dropped() signal, so it's always guaranteed that the
buffer stays alive until the reference count is checked.
The GraphicsBuffer::dropped() signal is used to remove the mapping
between wl_resource and ShmClientBuffer when the corresponding
wl_shm_buffer object is destroyed. On the other hand, we could perform
such cleanup when calling drop() too. This code can be further improved
by reimplementing wl-shm, which we need to do at some point in the
future.
This change introduces InputDevice::pointerFrame(). The main motivation
behind it is to allow batching multiple pointer events within a single
event frame.
BUG: 454428
