ShapeCursorSource provides the contents of the given cursor shape in the
Xcursor theme.
If the given cursor shape is animated, ShapeCursorSource will keep
updating its content based on the value of current sprite's delay value.
It ensures that connector type naming is consistent across compositors
and saves us some work adding string mappings.
drmModeGetConnectorTypeName() uses the same naming scheme as the drm
backend so the client side should be unaffected by this change.
CCBUG: 385135
Removing modifiers one by one creates a huge amount of combinations that
can make KWin hang for a long time in some cases. Instead of doing that,
leave it up to Mesa to pick a modifier when a setup doesn't work, which
will generally result in the least amount of bandwidth used and should be
able to power all output combinations.
The main motivation behind this change is to reduce the number of
geometry properties, in particular limit the use of clientPos that can't
be expressed as an alias to clientGeometry().topLeft().
The client geometry is not useful to scripts as they lack functions to
go from one type of geometry to another. The scripts use exclusively the
frame geometry.
The client geometry is not that useful in kwin too, similar to scripts,
almost all our window management code works with frame geometry. Client
geometry is useful when requesting the client to resize the window.
When setting a device's output name externally we assign the relevant output to the device
If we pass an empty name we set a null output, which causes a crash the next time the touchscreen is touched
Since passing an empty name semantically means 'Detect output automatically' rerun the mapping heuristic so we get a valid output
If this function is useful to make sure we are properly aligned with the
output's pixels, we should start with the output's 0, otherwise we'll be
carrying over the rounding errors increasingly as our workspace grows.
BUG: 459373
Using OutputBackend::outputsQueried can cause problems because it's emitted
before output settings like enablement get adjusted to the new output configuration.
It also doesn't react to output changes initiated by KScreen and is in the
way of plans to use multiple output backends at the same time.
BUG: 461901
This effect has a search field that doesn't actually search; it filters
through open windows. Let's change its placeholder text to reflect this,
so users don't get confused.
Currently, OutputBackend stores the initial state for windowed backends.
It's messy because the backends can have different needs. Instead, make
windowed backends take an Options struct with all possible options.
It allows us to encapsulate SurfaceItem rendering. It's needed to add
support for YUV->RGB conversion fallback path.
Effects that use this property must be ported to OffscreenEffect, see
also OffscreenEffect::setShader().
This is a BREAKING CHANGE!
The server-decoration protocol is deprecated, and the clients should use
the xdg-decoration-v1 protocol instead.
kwin will indicate that it wants server side decoration. If the host
compositor insists on client-side decorations, the wayland backend will
render no csd. However, this is de-facto state at the moment too,
perhaps it can be improved by using libdecor?
Regardless, no csd is the current state too, except that both host and
nested compositors can enter a loop where one side says to use CSD and
the other side says that they want SSD.
OutputBackend has a concept of readiness. When the host compositor goes
down, the OutputBackend will be marked as not ready, and when it
reappears, the output backend will be marked ready again.
On the other hand, host compositor going down is a niche case, it's not
something that often happens and it's hard to justify adding more moving
parts to the startup code. It's easier to call initialize() and check
whether it fails rather than call initialize() and then monitor isReady.
Therefore, this change drops OutputBackend::isReady() to make startup
simpler.
