Without the KWindowSystem integration plugin, Wayland experience will be
negatively affected because windows created by kwin itself won't behave
as desired. Therefore it makes little sense to load this plugin at runtime.
QTRY_COMPARE doesn't work well with how we do our wayland event
dispatching.
We know the client hasn't processed any events yet, so we can safely do
a normal wait.
On wayland, we know we're always going to load our internal QPA. Instead
of shipping a plugin and loading it dynamically we can use Qt static
plugins.
This should result in slightly faster load times, but also reduce the
number of moving pieces for kwin.
This also prevents anyone outside kwin loading our QPA which wouldn't
have made any sense and just crashed.
A window id generated by WaylandServer may reference an X11 window
with the same id, which can result in undefined behavior.
The main reason why we needed windowId() was because of the task
switcher. However, since tabbox uses internal ids now, the window id
property can be dropped.
SurfaceInterface::inputIsInfinite() has been dropped. If the surface has
no any input region specified, SurfaceInterface::input() will return a
region that corresponds to the rect of the surface (0, 0, width, height).
While the new design is more robust, for example it's no longer possible
to forget to check SurfaceInterface::inputIsInfinite(), it has shown some
issues in the input stack of kwin.
Currently, acceptsInput() will return false if you attempt to click the
server-side decoration for a surface whose input region is not empty.
Therefore, it's possible for an application to set an input region with
a width and a height of 1. If user doesn't know about KSysGuard or the
possibility of closing apps via the task manager, they won't be able to
close such an application.
Another issue is that if an application has specified an empty input
region on purpose, user will be still able click it. With the new
behavior of SurfaceInterface::input(), this is no longer an issue and it
is handled properly by kwin.
Currently, Qt clients send two maximize requests separated by the
initial commit. From spec's perspective, this is totally fine, the
client should receive two configure events with "maximized" state.
But because changeMaximize() in XdgToplevelClient and setMaximized()
operate on two different maximize modes, the second maximize request
will trick kwin into thinking that the client should be restored.
If Xwayland has crashed, the Workspace will block stacking order updates
and start destroying all X11 clients.
Once stacking order updates are unblocked, the Workspace will mark the X
stacking order as dirty and create a new Xcb::Tree object.
We don't want to create that Xcb::Tree object because accessing it
after the XCB connection has been shut down will lead to a crash.
BUG: 427688
FIXED-IN: 5.20.1
VirtualKeyboard class does not implement the relevant VirtualKeyboard
protocol but rather implements the InputMethod protcol and can in theory
be used by other input method like e.g. ibus.
Make class name consistent with what it does to avoid confusion in
future.
For now only rename of main class is done and dbus service is kept as-is
to provide retro-compatibility, when input method protocol is
implemented fully, we can think of what to do wrt the dbus interface
later when we fully implement zwp_input_method_unstable_v1 protocol.
This change replaces the remaining usages of the old connect syntax with
the new connect syntax.
Unfortunately, there are still places where we have to use SIGNAL() and
SLOT() macros, for example the stuff that deals with d-bus business.
Clazy was used to create this change. There were a few cases that needed
manual intervention, the majority of those cases were about resolving
ambiguity caused by overloaded signals.
If the Xwayland executable can't be found, the whole session will die
because a criticalError() signal will be emitted.
This change replaces the criticalError() signal with a less severe
signal.
If the errorOccurred() signal has been emitted during the startup
sequence, kwin won't die and will just continue with spawning the
session process.
After splitting out the server part of KWayland into a separate repo,
all non-core protocol wrappers in KWayland::Client had become obsolete
and using them in new projects is highly discouraged.
QPointer is a really useful way to store a pointer over time.
It doesn't make have any value as a return value used by a short-lived
method.
There isn't a good copy constructor, it's effectively the same as
creating a new QWeakPointer reference that has to be cleaned up.
Testing if something is null is still the same. A new QPointer can be
made by the caller if it actually is needed.
Input handling is a very hot path called many times a frame, so it's
important to keep this light. focus() and at() are called a lot which
added up to slightly over 1% of CPU time when moving the mouse about.
The layer-shell protocol allows wayland clients to create surfaces that
can be used for building desktop environment components such as panels,
notifications, etc.
The support for the plasma-shell protocol will be dropped once plasma in
all its entirety is ported to the layer-shell protocol.
in XdgSurfaceClient setFrameGeometry is async,
so we can't rely on it having the final value immediately.
make setVirtualKeyboardGeometry a virtual.
in the implementation on setVirtualKeyboardGeometry
use requestedFrameGeometry() instead of frameGeometry()
If the Xwayland process has crashed due to some bug, the user should
still be able to start applications in Xwayland mode. There is no reason
to restart the whole session just to be able to launch some application
that doesn't have native support for Wayland.
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
If the Xwayland process crashes, it will bring down the entire session
together with itself. Obviously, we don't want that. At least, Wayland
clients should survive the crash.
This change refactors relevant X11 parts to handle Xwayland crashes in a
less fatal way.
In order to handle Xwayland crashes better, a pair of start() and stop()
methods had been introduced in the Xwayland class to allow starting and
stopping the Xwayland process at any moment.
If we detect that the Xwayland process has crashed, we will immediately
stop the Xwayland server, which in its turn will deactivate the socket
notifier and destroy all connected X11 clients. Unfortunately, a couple
of subtle changes in X11Client::releaseWindow() and Unmanaged::release()
had to be made to ensure that we are left with a valid state after the
Xwayland server has been stopped.
Currently, the trend is to get the coordinates of the hotspot and map it
to the device independent pixels at the call site.
This change makes the KXcursorSprite return the coordinates of the hotspot
in the device independent pixels to reduce the amount of duplicated code.
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
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.
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.
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
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.
