We map AltGr to Qt::GroupSwitchModifier, but then ignore it
Instead map it to Mod5, which for some reason xkbcommon doesn't expose a define for
Also, since the Qt modifiers enum doesn't map nicely to XKB modifiers introduce our own enum to avoid confusion
CCBUG: 444335
If identity transformations aren't properly optimized out, we can have additional
rounding errors and reduced performance. This test ensures that doesn't happen
After !5532 existing behavior in public scripting API was changed for maximized Windows.
Maximized Windows didn't have a tile on purpose.
This behaviour was changed, as after refactoring separate members for storing QuickTileMode in Window and tile itself were unified
Previously QuickTileMode::Maximize was only set in the Window itself in m_quickTileMode, while tile itself was removed (by setTile(nullptr)).
Current QuickTileMod for current Window isn't part of public scripting API, so it's okay to break it.
This restores compatability with scripts created for KWin 6.0.5 and earlier
BUG: 489463
Signed-off-by: Alik Aslanyan <inline0@pm.me>
This exposes the degamma->ctm->gamma pipeline as a drm color op, which can
be set to a generic color pipeline. The same code can later be adapted to
program the upcoming per-plane color pipeline properties.
These flags affect kwin in general so WaylandServer is not the best place
for them to live in. For such things, we typically add properties in the
Application object, which is what this change does.
We do not snap to docks (i.e. panels) since the ones we
actually want to snap to (i.e. always visible ones) will
restrict the workspace area, and the window will snap to
that, effectively snapping to the panel too. Explicitedly
avoiding panel snapping solves any possible issue of
floating panels, since they change their size when a window
gets near them.
There were two problems preventing it from working:
1. The placement tracker didn't handle them correctly; now it sets the custom tile mode
after moving the window to its location
2. The window code used `output()` instead of `moveResizeOutput()`, which means when KWin
just moved the window to a different screen and immediately changes the tile mode
afterwards, it would tile the window on the wrong output
There were two problems:
1. Workspace interacted with the tile mode of windows before inhibiting
the placement tracker, so the wrong window state was stored in the placement
tracker
2. Window::setQuickTileMode is unintuitive and has some undesired side effects,
meant to handle quick tiling with keyboard shortcuts and by dragging the
window with a mouse specifically. This commit just works around that by
un-setting the tile mode first
BUG: 461886
Drm planes aren't specialized enough to need completely separate code paths to
handle them, and having one class for all layers makes it easier to add support
for overlay planes
This moves some of the responsbilities up in the stack, which simplifies
the backends and opens up some future possibilities like making direct scanout
work for non-surface items
Hidden moveResize() calls stand in the way of making geometry code
reusable or more refactorable. They also usually require one using
geometry update blockers, which are just a horrible concept because
they make geometry code unnecessarily more complex and add more failure
points.
The quicktileMode member now is just for the requested tile mode, base the "real" mode only on m_tile.
The requested tile mode is used for double buffering, to look and behave just like requestedMAximizeMode() which is updated immediately, but needs to acknowledge the configure request and render for quickTileMode() (and the right tile() instanced to be associated) to be updated accordingly
Currently the edge erroneously triggers when the pointer repeatedly
enters and leaves the edge in short durations. Send all events to edges,
and reset the timer when pointer leaves edge. Add corresponding test.
BUG: 441892
FIXED-IN: 6.0.4
Because of a shortcoming in upstream qtwaylandscanner and the cmake
macro we defered to the ecm macro which renames the output files
acoording to what qtwaylandscanner expects. However since this
was corrected in newer Qt this doesn't build anymore since
the tool now expects correctly named files.
Otherwise it's theoretically possible to create a new ClientConnection
object for the zombie wl_client when its resources are being destroyed.
For example
- process early wl_client destroy notification
- the ClientConnection objects gets removed from the client list in Display
- process wl_resource objects getting destroyed
- if some code calls display->getConnection(zombie_client), it's going to
reintroduce the client in the client list
- process late wl_client destroy notification, it's going to destroy the
original and the clone ClientConnection object
This change prevents reintoducing a clone client object, by keeping the
original for a bit longer until it's actually destroyed. In the future though,
it would be great to kill the client lists in Display and ClientConnection,
and just use `static_cast<ClientConnection *>(wl_client_get_user_data())`.
As Wayland doesn't have a warp event yet, before this commit, warps were
dealt with like normal absolute motion events. This trips up games though,
which don't deal with actual absolute motion events well. As a solution
to that, until an actual warp event is a thing, we send a motion event with
a position + a relative motion event with no motion
BUG: 458233
CCBUG: 482476
Make a roundtrip to the x server to ensure that WM_STATE changes have
been propagated. xcb_flush() is not good enough, there's still a race
condition between the wm flushing its connection and the client reading
window properties.
our plasmoid only listens to signals when the interface was found.
also when switching from 2 to 1 layout we'd emit a signal that the
layouts changed but then we'd throw away our interface leaving
the client wondering what happened to us (and consequently
printing warnings because our service wasn't found)
this specifically resulted in the plasmoid not getting layout event
changes when switching from 1 to >1
BUG: 449531
Unlike X11, on Wayland, the window won't change its maximize mode until
it renders a new buffer. This creates a problem for interactive move
because if it's not careful and moves the window while it's still effectively
maximized, it will look as if the window has leaked to other screens.
This change fixes the problem by making Window::handleInteractiveMoveResize()
avoid move() if the window needs to be unmaximized.
As a bonus, it also allows to unmaximize the windows that are maximized
along only one dimension by dragging them.
Unfortunately, tiling stuff still suffers from the same issue. In order
to fix it, Window::tile() has to be part of double buffered state, like
Window::maximizeMode().
BUG: 449105
BUG: 459218
CCBUG: 482085
XKB_KEY_KP_9 is 0xffb9 while XKB_KEY_KP_Equal is 0xffbd and XKB_KEY_F1
is 0xffbe. So XKB_KEY_KP_Equal, instead of XKB_KEY_KP_9, has the maximum
keysym for keypad keys.
Allow users to configure a virtual edge barrier between screens.
The pointer will only cross over to the other screen after the distance
travelled surpasses edgeBarrier.
Reduce the speed during interactive moveresize, at edges that trigger,
and at the corner.
Only supports wayland. Doesn't have X11 support since it is far too
complicated there.
BUG: 416570
BUG: 451744
When the output layout changes, the Workspace is going to update the
struts and then go through every window and see whether it should be
moved or resized.
On the other hand, the layer shell windows react to output changes on
a timer. Furthermore, it's not synchronized with the workspace rearranging
the managed windows. It means that when Workspace::desktopResized() runs,
the panel struts can be slightly outdated, i.e.
- An output layout change occurs
- Workspace::desktopResized() is called but the struts can be wrong
- some time later, LayerShellV1Integration::rearrange is called, it
fixes layer shell window geometries and struts
- after the layer shell integration has finished rearranging the
layer shell windows, it calls Workspace::desktopResized(), but the
damage had already been caused
With the proposed change, the Workspace and the LayerShellV1Integration
will rearrange the windows in sync.
CCBUG: 482361
Now that we have Wayland around, there's a whole branch of dependencies
that shouldn't be necessary anymore.
This allows to build KWin without all of it, allowing us to have a much
more compact alignment for cases where all the legacy software isn't
necessary anymore.
Bundle KWindowSystem X11-specific headers into it too, since it's part
of the same process.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
If the client is slow, kwin can receive _NET_WM_MOVERESIZE requests
after user has released mouse buttons. Ideally, the window manager
should refuse starting an interactive move/resize operation in such a
case so it's still possible to finish moving or resizing the window
by releasing mouse buttons.
Strict geometry disables certain user activites; full screen requests
and only sending configure events at sizes the client claims to support.
This was added as a workaround for xterm in 19 years ago. It's a client
side bug as applications can still choose to ignore the configure event,
so kwin shouldn't have to sanitise them in advance. xterm seems to have
fixed it's bug, and pragmatically we know not all window managers
perform these checks so most clients should not be relying on it.
On Wayland this additional check is proving problematic, the handling of
scaling especially fractional scaling is hitting cases where it's better
to always ask the client to do what kwin wants.
Tests that refer to sizeIncrements are dropped as they are only used in
the strict geometry passes which is being obsoleted. Resizing in general
is still tested.
BUG: 481456
NETWM forces a weird X11 dependency on KWin that doesn't necessarily
match what we want to do. Instead we decouple such a central class in
KWin like it's Window from KWindowSystem X11 support.
Signed-off-by: Falko Becker <falko.becker@mbition.io>
SeatInterface currently has a separation of kwin's focus scope to
pointer input with early return guards in notifyPointerEnter and
notifyPointerLeave where clients don't get pointer events.
However we don't update the initial state when a drag is started, this
patch notifies sends a pointer leave to the new drag target before the
data_device enter so things are consistent.
This also brings it in line with Weston and Mutter.
notifyPointerLeave has it's early return removed as for wayland windows
as we know nothing will have pointer focus.
There is a mix of cursor shape names from the CSS W3C specification and
non-spec ones, which is confusing when deciding what cursor shapes need
aliases in Cursor::cursorAlternativeNames().
The current implementation of the `<N>` suffix is still buggy and its
benefits are doubtful. One could argue that visual aids such as window
thumbnails or highlighting the windows are better. On its own, these
numbers don't have strong connections to the windows and can change on
a whim.
This was just done because of the wrong assumption that displays needed that
to show the full native gamut. That turned out to be an amdgpu bug though; with
that fixed, most of the 0-100% range is wildly oversaturated.
To make the slider more intuitive, this changes the sdr gamut wideness to instead
interpolate to the native display primaries as indicated by the EDID.
At the moment, the desktop layout in _NET_DESKTOP_LAYOUT overwrites new
desktop layout with outdated information. This happens because kwin tries
to honor the desktop layout set by the pager. However, kwin itself
already acts as the pager. The pager applet in plasma doesn't attempt to
maintain _NET_DESKTOP_LAYOUT with proper values.
On the other hand, kwin trying to both update and also sync its state to
_NET_DESKTOP_LAYOUT and _NET_DESKTOP_NAMES has created a series of
issues, like lockups or rendering glitches.
Given that the window manager can ignore these properties, and the fact
that kwin already does act like a pager, this patch makes kwin ignore
external updates to _NET_DESKTOP_LAYOUT and _NET_DESKTOP_NAMES.
In order to modify the desktop layout on X11, use the dbus api. On
Wayland, either the dbus api or the virtual desktop wayland protocol.
BUG: 422319
BUG: 480371
A window is added to the workspace when it's mapped. It's assumed that
the first Window::windowShown signal indicates that. But it's not
entirely true. For example, if setHidden(false); setHidden(true); are
called in succession, the window will be marked as ready for painting
even though it isn't.
The Window::readyForPaintingChanged() signal fixes that. It's emitted
when the window is actually mapped.
At the moment, if the workspace extends or shrinks by an output, the
hidden panel will be shown. It doesn't make sense in all cases.
Furthermore, no screen edge will be reserved if the layer surface has
some margins.
To address that, allow "floating" panels reserve screen edges and also
make kwin try harder to preserve window edges if the output layout
changes.
CCBUG: 448420
