in a CI context the paths are mutable between installation and use
and as such the permission checks can just not ever work. for use
in such scenarios allow completely disabling the permission checks
* Allow to do quick tiling to custom tile geometries, windows will be snapped to tiles when dragged with the shift modifier pressed.
* Tile geometries are screen specific.
* The global shortcut Meta+T will trigger a fullscreen configuration ui as a QML effect for the tiles which allows to add, remove and resize tiles
* UI and behavior is a bit similar to the Windows Fancy Zones addon: https://docs.microsoft.com/en-us/windows/powertoys/fancyzones
* Its main scope is to help the workflow with very big monitors, especially ultra wide ones, where most application don't make sense maximized to the full screen (eventually also support games to be full screened to a given tile instead of the whole screen)
* it should get also some bindings for scripting, as its ain goal is not to replicate other popular tiling window managers, but should give the popular kwin tiling scripts to have a more robust infrastructure
* it will eventually get support for a set of predefined layouts, but this is for a second phase
BUG: 438788
The previous logic would set `defaults` to the last found group.
Since a touchpad is a pointer, it would set `defaults` to point
to `[Libinput][Defaults][Pointer]`, and thus the next clause would
try to find `[Libinput][Defaults][Pointer][Touchpad]`, instead of the
expected `[Libinput][Defaults][Touchpad]`. That is, only if a default
was set for Pointer.
Signed-off-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
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
Natalie Clarius