Currently, if the pointer is locked, the wayland backend will create a
subsurface. However, when the cursor moves to one of the screen edges,
it looks weird because the xdg window geometry is computed as bounding
geometry of the main surface and its subsurfaces. However, even after
calling xdg_surface.set_window_geometry, it still looks weird because
subsurfaces are stacked above window decoration.
With the proposed change, when the pointer is locked, the wayland
backend will hide the host compositor and use the software cursor. If
the pointer is unlocked, it will go back to using host cursor.
Long term goal is to make every output have its own cursor to make
output layer logic simpler.
Mesa's implementation of wl_egl_window_resize() is pretty smart. It
avoids immediately resizing the buffers. On the other hand, its API
doesn't enforce that behavior and other implementations of wayland-egl
may choose to use a different strategy.
This change moves wl_egl_window_resize() to beginFrame() to make buffer
resizing handling more nicer. Also, for the record, the drm backend
works in similar fashion.
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
