These concepts are hard to map to InputDevice abstractions, so remove
them and let kwin use its own internal keymap instead (rather than
get it overridden by the host compositor's keymap) and track modifiers
based on the events it receives.
If the goal is to have these at any cost, I think the way out of it
would be to provide wayland backend specific signals. I would like to
avoid doing that though because it breaks encapsulation and we would
need some casts in kwin to wire in these events.
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!
