Kwin's VirtualDesktop saved a different configuration per X screen. This
messes up with a recent refactor of our startup as now we load
virtualdesktops before the X11 screen number is set and we load from the
group "Desktops-screen--1" then save to another place.
For a wayland session it doesn't make sense to have such a strong X
tie-in. We may as well just tidy this up.
Multihead has been deprecated for a decade. There is absolutely no way
Plasma supports it. Worst case if someone magically is using mutlihead
they just get syncronised virtual desktops.
BUG: 424571
In rare cases, Workspace::restoreFocus() may fail, for example when the
most recently activated client is about to be destroyed or unmapped.
If it happens that we cannot restore the focus, then mark the window in
FocusIn event as active.
CCBUG: 424223
Fix regression that was introduced by a mismatch in the default value of
ActiveMouseScreen option between kwin.kcfg and kwinoptions_settings.kcfg
BUG: 424389
(cherry picked from commit c853f8313a213a0f7d0f98f662f7e98849d547ca)
If AbstractClient::setFrameGeometry() is called from a slot connected
directly to the frameGeometryChanged() signal, then is there a good
chance that kwin will fall into an infinite recursion. However, that's
the case with only X11 and internal clients.
The root cause of the infinite recursion is that both X11Client and
InternalClient compare the new geometry against the geometry before
update blocking. In order to fix the bug, we simply need to ensure that
updateGeometryBeforeUpdateBlocking() has been called before we start
emitting the frameGeometryChanged() signal.
Furthermore, a couple of tests were added to ensure that we won't hit
this subtle bug again.
Unfortunately, a0c4a8e766 has a major bug
where clients that track focus events may get confused by focusToNull().
One such a notable example is Dota 2. It tracks the focus events to
minimize itself after the keyboard focus has been lost as well stop
playing music while it's in background. So, when we call focusToNull(),
Dota 2 will receive a corresponding FocusOut event and ask the window
manager to minimize it. It doesn't really matter that the FocusOut
event is going to be followed by a FocusIn event because when a window
is minimized, kwin will activate the next one in the focus chain.
Since those issues can't be fixed from the window manager's side, this
patch partially reverts a0c4a leaving only the autotest.
BUG: 424223
FIXED-IN: 5.19.4
Implemented for Global, Virtual Desktop and Application layout policies.
Not implemented for Window policy due separate windows do not preserve
their IDs between sessions (still could be implemented the same way as for Application policy).
Layout saving/restoring happens on Session save/load.
Covered by unit tests
Currently, we update the input transformation matrix for the focused
pointer surface only when the frameGeometryChanged() signal is emitted.
However, since the input transformation matrix is computed based on the
current position of the upper left corner of the main surface, it is
wrong to do so because the frame geometry is a logical geometry that
doesn't have any direct relationship with the buffer geometry, i.e. the
rect on the screen occupied by the main surface.
If the input transformation matrix gets out of sync, user may notice
that pointer events are "shifted."
This change introduces a new signal that's emitted when the input
transformation matrix has been changed. Input related components in kwin
can connect to it to keep a copy of the input transformation matrix in
SeatInterface in sync. Under the hood, the new signal is just an alias
for the bufferGeometryChanged() signal.
The new signal can be useful if one wants to watch a toplevel for buffer
geometry updates. This can be especially useful for input related code
because the position of the upper left corner of the main surface is used
to compute the input transformation matrix.
Currently, the test passes because the activities controller doesn't
have enough time to fetch all activities. So, the test client won't be
placed on the current activity.
Since the Workspace is now created before starting the Xwayland, we now
spin the event loop, which allows the activities controller to fetch the
list of all activities and so the test client will be placed on the
current activity, i.e. client->isOnAllActivities() will no longer return
true.
This change fixes wrong assumptions in the test and makes it robust.
Sub-classes of the AbstractClient class need a valid instance of the
Workspace class to function as desired. We should not create xdg-shell
clients until the workspace is created.
The new signal is emitted when the Application has fully been initialized.
It allows us to change the startup sequence, for example create workspace
before starting the Xwayland server, without making any adjustments in our
test suit.
It was called twice once with and without X as our implementation of
setRootInfo() missed some calls.
This was done to avoid a bug as setRootInfo() didn't update everything.
This patch aims to resolve that at the root cause.
I tested the original conditions of the patch with an empty kwinrc and a
file in /etc/xdg/kwinrc setting desktops to 2 and everything loaded
correctly.
Don't give the InputConfig a separate config instance. I've seen it
being changed after having initialized the xkb instance which would
break the shared instance.
Using a simple config rather than reading the configuration from
the actual code-path shouldn't make a difference as a test it will be
using ~/.qttest which should be cleaned upp
We may call setActive() on a window that is being deleted. We cannot
guarantee that at that moment the X11 window or the Wayland surface is
still valid. So, the best course of actions is to do nothing.
BUG: 424255
Screens are set during init, to do so at cleanup doesn't bring a lot.
It leads to a potential awkward raciness with xwayland failing the test,
whilst doing something that isn't part of what we're testing here or
likely to happen in real life.
On 5.15, the VirtualKeyboard did not have a correct z-order which caused
the virtualkeyboard to hide as soon as key was pressed, upon
investigation it seems that upstream Qt changed behavior in following
changes.
https://codereview.qt-project.org/c/qt/qtvirtualkeyboard/+/292472https://codereview.qt-project.org/c/qt/qtvirtualkeyboard/+/292674
Now when desktop-integration is used (i.e non-application embedded mode)
one need to set property desktopPanel to true so that it have correct
z-ordering and does not miss input events.
This is used in Component.onCompleted to avoid breaking it for the Qt
5.14.x qtvirtualkeyboard. When we switch to 5.15 property assignment can
be moved to InputPanel declaration.
Xwayland can operate in two modes - rootless and rootful. When Xwayland
operates in the rootful mode, a container window is created where all
native X11 clients are placed. The container window is an xdg-toplevel
surface. Most compositors are not interested in rootful mode.
When Xwayland operates in the rootless mode, every X11 window is going
to be represented with a Wayland surface that has no role assigned to it.
In order to associate a wayland surface with an X11 window, Xwayland
will send a client message of type WL_SURFACE_ID.
Since we want Xwayland operate only in rootless mode, the check that
verifies that a newly created xdg-toplevel surface belongs to Xwayland
is pointless. We are never going to hit that case.
We were calling it from tests that were not running a KWin::Application
and not even including the symbols from main.cpp and main.h. The only
reason they linked was that it was static_casting up the QCoreApplication.
When the display is set to 30-bit depth (10-bit per color component),
decorations of some clients appear garbled when compositing is disabled.
This is because the pixel format of the QImage in which the decorations
were rendered differed from the the X pixmap into which the pixels were
being copied by means of xcb_put_image().
For lack of a more robust way, this change guesses A2RGB30 for depth=30,
and keeps using ARGB32 as before for any other depth. I don't expect
anything other to 32bpp to be supported by KWin anyway.
Tested on amdgpu with KWIN_OPENGL_INTERFACE=egl.
BUG: 406302
FIXED-IN: 5.19.4
