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
It is possible for updateOutputs to be called when a pageflip is pending.
Freeing a DrmOutput with a pending pageflip is not allowed (see ~DrmOutput assert - the page flip handler will be called on the freed memory, possibly leading to use-after-free).
This works around the problem by delaying the destruction with teardown().
BUG: 422460
In atomic setting mode, when external display tears down, it will blank
crtc with dump buffer by legacy api, then re-plug the external display,
the blank can not be removed. We think the blank is not needed in atomic
mode setting.
Signed-off-by: Chaojiang Luo <chaojiangluo@163.com>
The surface size is a logical size, which renders it unsuitable for
deciding whether the window pixmap needs to be discarded.
We need to discard window pixmaps when the buffer size changes. That
has a drawback though, discarding textures is kind of an overkill with
linux-dmabuf. However, fixing that would involve changes in kwayland
server that are far from being trivial.
BUG: 422459
In order to ensure that no configure events will be sent before the full
initial state is committed, we need to queue maximize and full screen
requests or else the client may receive an "unexpected" configure event
and we miss to call initialize().
It was udpated when we received a configure event but not in the initial
track.
The symptom of this being missed out was that blur would not be applied
to the window.
BUG: 423405
CCBUG: 423297
A seemingly unrelated change to cursors broke xwayland's clipboard
syncing, presumably because of a change in how startup is ordered with
regards to syncing between our internal wayland connection causing a
crash.
It was fixed with a flush, but ultimately guarding things coming up in
the natural order works better.
Long term plans are to finish removing the internal connection.
See xwayland_selections_test in autotests.
When the user selects all of the types or none of them, the "types"
property must be set to a special value (`NET::AllTypesMask = -1`),
different than the sum of all the flags together.
This re-implements this behaviour as the old KCM, fixing some heuristics
that prevented finding the rule corresponding to the current window.
The enum name that handles this property has been changed to `NetTypes`
to make it more explicit.
BUG: 423214
FIXED-IN: 5.19.3
TEST PLAN:
1. Open the `Application specific settings` on a window via menu
2. Select every "Window Type" (or none of them)
3. Give the rule a different name than the default and save
4. Open it again and check that the same rule is found
Depending on the current focus stealing prevention level, it's possible
for kwin to call XSetInputFocus() on a window that already has the input
focus. In which case, we won't receive the corresponding FocusIn event
and the client will remain inactive from kwin's perspective even though
it isn't.
In order to work around this issue, we can move the input focus to the
null window. By doing so, it's guaranteed that we're going to receive
the matching FocusIn event for the client.
This commit indirectly fixes a bug where fullscreen games are displayed
below panels.
