KWin does not update activity status when setting `_KDE_NET_WM_ACTIVITIES`
to nullUuid outside of KWin, which causes "All Activities" not working
as expected for KWindowSystem.
`X11Client::activityList` is not kept in sync with
`AbstractClient::m_activityList`. Move `m_activityList` from private to
protected, and use it in `X11Client::readActivities`
BUG: 440496
Currently, if a window switches between SSD and CSD, it is possible to
encounter a "corrupted" state where the server-side decoration is wrapped
around the window while it still has the client-side decoration.
The xdg-decoration protocol fixes this problem by saying that decoration
updates are bound to xdg_surface configure events.
At the moment, kwin sort of applies decoration updates immediately. With
this change, decoration updates will be done according to the spec.
If the compositor wants to create a decoration, it will send a configure
event and apply the decoration when the configure event is acked by the
client. In order to send the configure event with a good window geometry
size, kwin will create the decoration to query the border size but not
assign it to the client yet. As is, KDecoration api doesn't make
querying the border size ahead of time easy. The decoration plugin can
assign arbitrary border sizes to windows as it pleases it. We could change
that, but it effectively means starting KDecoration3 and setting existing
window deco ecosystem around kwin on fire the second time, that's off the
table.
If the compositor wants to remove the decoration, it will send a
configure event. When the configure event is acked and the surface is
committed, the window decoration will be destroyed.
Sync'ing decoration updates to configure events ensures that we cannot
end up with having both client-side and server-side decoration. It also
helps us to fix a bunch of geometry related issues caused by creating
and destroying the decoration without any surface buffer attached yet.
BUG: 445259
Currently, AbstractClient::geometryRestore() is abused to put windows
back on their original screen. It makes window placement more complex
and it breaks restoring initially maximized windows.
After the decoration is destroyed, we need to resize XdgToplevelClient
to ensure that the scheduled configure event will have correct size.
As is, xdg-toplevel configure events are delayed. When it's actually the
time to send a configure event, XdgToplevelClient will compute the
requested client size from the moveResizeGeometry().
If the moveResizeGeometry() still includes window decorations, the
window will get bigger.
BUG: 444119
Currently, adjustedSize() does two things - it computes and constrains
the natural size of the window.
In many places where adjustedSize() is used, the natural size doesn't
need to be constrained and in some it's actually undesired because
AbstractClient::constrainClientSize() doesn't allow the client size to
be 0x0, which can happen when dealing with a client that has no buffer
committed yet.
This change replaces adjustedSize() with implicitSize(), which simply
calculates the natural frame size based on the current client size.
If the frame size needs to be constrained, for example during
interactive move-resize, use constrainFrameSize() or if you need to
constrain the client size - constrainClientSize().
With the recent AbstractOutput changes, Workspace::clientArea() overload
that takes only the window and no additional output was changed to
return clientArea(opt, window, window->output());
prior to that, it had been looking up the output at the center of the
frame geometry.
As it turns out, AbstractOutput::sendToOutput() blocks geometry updates,
which in its turn means that Toplevel::output() will be updated only
after geometry updates are unblocked. For the most part, it's not a big
deal until you need to use Workspace::clientArea(opt, const Toplevel*)
Since the output won't be updated until geometry updates are unblocked,
clientArea(opt, const Toplevel *) may return outdated info.
One could argue that we just simply need to update m_output similar to
m_frameGeometry when geometry updates are blocked, but... it's not going
to work on wayland! On Wayland, GeometryUpdatesBlocker is totally
unnecessary. Even if a window is resized, m_frameGeometry will be left
unchanged until the client repaints the window.
Instead, one need to pass the AbstractOutput to clientArea() if it's
important.
This change makes X11Client::changeMaximize() query the MaximizeArea of
the output containing the center of the move resize geometry, similar to
what the XdgToplevelClient does.
BUG: 442534
If the buffer size changes after creating or destroying the decoration,
the surface item will discard the pixmap.
If the buffer size remains the same, we can continue using old pixmap.
xcb_send_event always copies 32 bytes, so we have to pad all xcb_*_event_t
to 32 bytes to avoid leaking uninitialized stack memory. I found this
problem while running kwin_x11 on a CHERI-RISC-V system (which has bounded
pointers). The xcb_send_event() implementation has a memcpy() that was
copying 32 bytes but the event passed was a bounded to 28 bytes, so this
resulted in a run-time exception in X11Client::sendClientMessage().
The same problem exists in Selection::sendSelectionNotify(), but this time
we could end up copying up to 8 bytes since xcb_selection_notify_event_t
is only 24 bytes.
This disclosure of uninitialized data could in theory have a security
impact if it leaks a pointer value (e.g. a return address) as part of an
exploit chain that needs to bypass ASLR. However, the selection notify
events go directly to the XServer and you most likely already have a
serious problem if an attacker has full control over the XServer. It is
possible that the configure notify events go directly to an untrusted
client, but even if they do this leak is not directly exploitable.
See also https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/18
This allows the decoration buttons to be updated accordingly
when the status changes.
We also need to explicitely update allowed actions when rules
are applied, as `isCloseable` is not a settable property, but
an allowed action
BUG: 424370
FIXED-IN: 5.22.90
Active output is a window management concept. It indicates what output
new windows have to be placed on if they have no output hint. So
Workspace seems to be a better place for it than the Screens class, which
is obsolete.
The new overloads take the client (as context) and the desired screen id
or a point and return the client area.
The main motivation behind this change is to make the transition to the
new virtual desktop model where a window can be on several desktops less
painful.
At this point, desktop() is -1 since the client hasn't been moved to any
virtual desktop yet.
It seems like checking desktop() is a typo. It makes more sense to check
desktopId.
This ports relevant apis in WindowRules to the VirtualDesktop class.
If the client has no desktop rule, the desktop list that has been passed
to the checkDesktops() function will be returned.
If the client has a desktop window rule, the checkDesktop() function
will return a list with a single VirtualDesktop object or none if the
window is forced to be on all virtual desktops.
toplevel.h is included in many places. Changing virtualdesktops.h may
trigger rebuild of all kwin.
With this change, only cpp files that use virtualdesktops.h will need to
be recompiled.
The main idea behind _NET_WM_FRAME_OVERLAP is to extend the borders of
the server-side decoration so the application can draw on top of it. It
was inspired by similar feature in Windows.
However, _NET_WM_FRAME_OVERLAP is basically unused. Neither GTK nor Qt
support it and I have never seen any application that uses it.
At the moment, kwin is the only compositing window manager that supports
_NET_WM_FRAME_OVERLAP. Neither mutter nor compiz nor compton and so on
support it.
Since _NET_WM_FRAME_OVERLAP is practically unused, there's no point for
keeping supporting it.
This change shouldn't affect any existing app as _NET_WM_FRAME_OVERLAP
atom is not listed in _NET_SUPPORTED.
It is error-prone to have multiple sources for the same data. If the
base implementation (Compositor::compositing()) changes, other helpers
can get out of sync.
If the window borders change in such a way that the buffer geometry
doesn't change, but the client geometry does change, we need to configure
the wrapper window and maybe the client window so there are no black
borders, etc.
Currently, there is an assumption in the moveResizeInternal() method
that if the buffer geometry changes, then the client geometry will also
change. However, as it turns out, it's not completely true. For example,
if the window is maximized while its geometry already matches the
maximize area, the buffer geometry won't change, but the client geometry
will change.
This change adds missing geometry checks. *geometryBeforeBlocking
corresponds to the old geometry. We can use it to decide if the geometry
has changed.
If the geometry window rule must be forced, the move resize method has
to force it, but similar to size constraints, we assume that the caller
of the move resize function will do the right thing. So, remove the
debug message to be consistent with other client types.
Currently, the implementation of the DecoratedClient and the decoration
renderer are strongly coupled. This poses a problem with the item based
design as the ultimate goal is to have scene items construct paint nodes
which are then fed to the renderer. The DecorationItem has to have
control over the decoration texture. Another issue is that the scene
cannot smoothly cross-fade between two window states if the decoration
is removed, e.g. from fullscreen mode to normal and vice versa.
This change moves the decoration renderer to the decoration item. With
the introduction of a generic scene texture atlas, we hope to get rid of
the decoration renderer altogether.
AbstractClient::doPerformInteractiveMoveResize() is only used by the
X11Client to reset a boolean flag when the client doesn't support sync
counters.
X11Client can call performInteractiveMoveResize() only in two cases: the
sync request timer expires or the client increments the sync counter.
This change removes the AbstractClient::doPerformInteractiveMoveResize()
function and adds a function to handle the case where the sync timer
expires explicitly. This removes a virtual function in the AbstractClient
and makes code more readable.
Window management features were written with synchronous geometry
updates in mind. Currently, this poses a big problem on Wayland because
geometry updates are done in asynchronous fashion there.
At the moment, geometry is updated in a so called pseudo-asynchronous
fashion, meaning that the frame geometry will be reset to the old value
once geometry updates are unblocked. The main drawback of this approach
is that it is too error prone, the data flow is hard to comprehend, etc.
It is worth noting that there is already a machinery to perform async
geometry which is used during interactive move/resize operations.
This change extends the move/resize geometry usage beyond interactive
move/resize to make asynchronous geometry updates less error prone and
easier to comprehend.
With the proposed solution, all geometry updates must be done on the
move/resize geometry first. After that, the new geometry is passed on to
the Client-specific implementation of moveResizeInternal().
To be more specific, the frameGeometry() returns the current frame
geometry, it is primarily useful only to the scene. If you want to move
or resize a window, you need to use moveResizeGeometry() because it
corresponds to the last requested frame geometry.
It is worth noting that the moveResizeGeometry() returns the desired
bounding geometry. The client may commit the xdg_toplevel surface with a
slightly smaller window geometry, for example to enforce a specific
aspect ratio. The client is not allowed to resize beyond the size as
indicated in moveResizeGeometry().
The data flow is very simple: moveResize() updates the move/resize
geometry and calls the client-specific implementation of the
moveResizeInternal() method. Based on whether a configure event is
needed, moveResizeInternal() will update the frameGeometry() either
immediately or after the client commits a new buffer.
Unfortunately, both the compositor and xdg-shell clients try to update
the window geometry. It means that it's possible to have conflicts
between the two. With this change, the compositor's move resize geometry
will be synced only if there are no pending configure events, meaning
that the user doesn't try to resize the window.
We have 2 equivalent code paths for x11 and wayland unnecessarily, unify
them under the same method.
Rename m_clients to m_x11Clients so that it's clear what the difference
is between m_clients and m_allClients.
They are used only by X11Client, so make X11Client call relevants
methods on the surface item directly instead. In hindsight, it will be a
really good idea to make SurfaceItemX11 and SurfaceItemXwayland(?)
automatically manage the window pixmap. However, it can be done once
an item freezing api is added and we fix the cross-fade animation.
This is to improve code readability and make it easier to differentiate
between methods that are used during interactive move-resize and normal
move-resize methods in the future.
This makes the implementation of the buffer geometry consistent with the
frame geometry and the client geometry and removes a virtual method call
from a few hot paths.
With the client-side decoration changes, kwin will properly determine
whether the window needs to be configured even if the frame geometry has
not changed.
This change slightly changes the semantics of the setFrameGeometry()
method. Prior to this, it was possible to force a geometry, i.e. block
other geometry updates, however such a behavior is counter-intuitive and
it exponentially increases the complexity of code.
As far as I know, the force flag was needed to propagate geometry
changes if the frame geometry doesn't change, but the client geometry
does. With the client-side decoration changes, the force flag is not
needed, as kwin now takes into account the client geometry and the frame
geometry when determining whether to send a configure event.
When the maximize mode changes from MaximizeFull to either
MaximizeHorizontal or MaximizeVertical, (max_mode & MaximizeFull) will
evaluate to true because MaximizeFull is defined as bitwise OR between
MaximizeHorizontal and MaximizeVertical.
This introduces the markedAsZombie signal, which is emitted when the
window is about to become deleted. The X11SurfaceItem uses this signal
to determine when the damage must be destroyed.
