When the tabbox grabs input, the key events won't be sent to the client.
It's not good for a couple of reasons: first, it can fool the client into
repeating a previously pressed key; and the server side and the client
side can be out of sync after the task switcher is dismissed.
In order to handle that properly, this change makes the tabbox reset the
keyboard focus when it's shown or hidden. When the task switcher is
dismissed, an enter event will be sent with the current state of the pressed
keys.
Ideally, the same needs to be done with the pointer focus but it's
challenging to achieve with the current input pipeline design. An input
grab abstraction is needed to handle pointer focus when the task switcher
is active.
This is needed to better support emitting mouse button events when
pressing tablet buttons. It's common in many art programs that an action
is tied to a mouse button + a modifier, such as panning the canvas. So
being able to send keyboard modifiers in tandem with mouse buttons is
very useful when rebinding.
Tests are added for this new feature.
CCBUG: 469232
KeyboardInterface is a multiplexer, it has a global state to kwin
that forwards events the single focussed window.
XWayland also forwards events to clients, but uses the keyboard interface.
It has some overloads that take a specific client, this was used for key events
but not modifiers.
The end result was not only that XWayland could miss a modifier update, but
also that wayland clients would get modifier updates out of order.
Key events must come first.
BUG: 490270
If an output is deleted, the Workspace::desktopResized() is going to
re-assign windows to the new outputs. It is done so so the workspace
re-arrangement procedure is deterministic and has concrete order.
However, with the current Window lifecycle management, it's possible
to encounter the follwing case:
- xdg_toplevel gets created on output A
- xdg_toplevel initial state is committed
- output A is removed
- a wl_buffer is attached to the xdg_toplevel, which results in a
geometry change and an output change
- Window::setMoveResizeOutput() is called, but the previous output
is a dangling pointer
CCBUG: 489632
Since the tablet cursor and the mouse cursor is tracked separately,
rebinding a tablet button to a mouse click is sort of wonky. For
example, if you assign it to Right Click and attempt to open a context
menu it will appear to open in the wrong place.
So before we send the mouse button event, set the mouse position to
the tablet cursor position. A test is added to ensure this functionality
works as intended and doesn't regress.
This is to not destroy the tablet state for the next test (which is
added in the next commit.) We could also explicitly do a tablet tool
up/down dance here, but all we need is the tablet tool to be in
proximity for the tablet button event to fire.
This adds autotests for binding to tablet pad and tool buttons, which
was previously untested. Of note is that we don't explicitly test mouse
buttons, which is already tested in the other functions.
NETWinInfo queries the window state and setState() will do nothing if the
proposed new state matches the cached server side state.
On the other hand, given how the test is structured, there can be pending
fullscreen changes on the kwin side that are yet to be sent to the X server
when the NETWinInfo object is created.
This change fixes that race condition by adding an explicit Xcb::sync().
The effect only modifies the opacity of individual windows that
WorkspaceScene::scanoutCandidate will reject anyways, so there's no reason
for it to block direct scanout.
Once a more proper solution for blocking direct scanout on individual items
is in place, this can be removed again
BUG: 487780
pipewire 1.2 has a known regression where the client's process callback
will not be triggered if the producer has sent only one buffer.
The issue has already been fixed upstream
525360d70a
Until our CI picks up that change, temporarily disable the test to unblock
merging patches.
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
