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.
Property `wmclass` of a window rule works in a special way, as it can have
two meanings depending on `wmclasscomplete` flag:
- false: only matches `resourceClass`
- true: matches `resourceName` and `resourceClass`
This MR fixes two subtle bugs when detecting the properties of a window:
In the first case, `resourceName` was being wrongly set instead, which
prevented window matching for windows where those two values differ.
Also, the `wmclass` field was always set to `resourceName` independently
of `wmclasscomplete` property.
BUG: 423138
FIXED-IN: 5.19.3
Due to a bug in the XI2 protocol, clients have to reset scroll valuators
on XI_Enter because the scroll valuators might have changed while the
pointer was elsewhere. The XI_Enter event is usually sent when an input
device enters the window, but it can also be generated by a passive grab.
If an XI_Enter event has been generated by a passive grab, the client
should not reset scroll valuators. Unfortunately, there is no any
reliable way for the client to determine if an XI_Enter event has been
sent in response to a deactivated passive grab. A correct fix for the
scroll issues in GTK apps would involve changes in the XI2 protocol.
As a work around, we can hold a passive grab only if the current mouse
wheel action is either "Activate and scroll" or "Activate, raise, and
scroll."
BUG: 394772
FIXED-IN: 5.19.3
