As it was pointed out in 6acf35e4cc, it is
better to return raw pointers than qpointers because returning a qpointer
is equivalent to constructing a new one.
Warning messages are not the kind of messages that should be ignored,
they indicate that something is off or wrong.
Also, this makes triaging bugs easier as we no longer have to ask people
to run kwin with the QT_LOGGING_RULES environment variable set.
This logs to a tracefs filesystem which can be viewed in tools such as
gpuvis to see precise timings of activities in relation to other trace
markers in X or graphic drivers.
This patch is loosely based on D23114. Though modified with thread
safety, support for string building, and a RAII pattern for durations.
Ultimately that expanded it somewhat.
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
At the moment, the Screens class is convoluted with ifdefs because of
MockScreens.
The goal of this change is to reduce the number of usages of the
MockScreens class so it is possible to get rid of the ifdefs.
Since the Screens class is a convenience wrapper around AbstractOutput
objects that come from the Platform, it should not be platform-specific.
By dropping createScreens(), output-related code becomes simpler.
This change introduces a new component - ColorManager that is
responsible for color management stuff.
At the moment, it's very naive. It is useful only for updating gamma
ramps. But in the future, it will be extended with more CMS-related
features.
The ColorManager depends on lcms2 library. This is an optional
dependency. If lcms2 is not installed, the color manager won't be built.
This also fixes the issue where colord and nightcolor overwrite each
other's gamma ramps. With this change, the ColorManager will resolve the
conflict between two.
Effects are given the interval between two consecutive frames. The main
flaw of this approach is that if the Compositor transitions from the idle
state to "active" state, i.e. when there is something to repaint,
effects may see a very large interval between the last painted frame and
the current. In order to address this issue, the Scene invalidates the
timer that is used to measure time between consecutive frames before the
Compositor is about to become idle.
While this works perfectly fine with Xinerama-style rendering, with per
screen rendering, determining whether the compositor is about to idle is
rather a tedious task mostly because a single output can't be used for
the test.
Furthermore, since the Compositor schedules pointless repaints just to
ensure that it's idle, it might take several attempts to figure out
whether the scene timer must be invalidated if you use (true) per screen
rendering.
Ideally, all effects should use a timeline helper that is aware of the
underlying render loop and its timings. However, this option is off the
table because it will involve a lot of work to implement it.
Alternative and much simpler option is to pass the expected presentation
time to effects rather than time between consecutive frames. This means
that effects are responsible for determining how much animation timelines
have to be advanced. Typically, an effect would have to store the
presentation timestamp provided in either prePaint{Screen,Window} and
use it in the subsequent prePaint{Screen,Window} call to estimate the
amount of time passed between the next and the last frames.
Unfortunately, this is an API incompatible change. However, it shouldn't
take a lot of work to port third-party binary effects, which don't use the
AnimationEffect class, to the new API. On the bright side, we no longer
need to be concerned about the Compositor getting idle.
We do still try to determine whether the Compositor is about to idle,
primarily, because the OpenGL render backend swaps buffers on present,
but that will change with the ongoing compositing timing rework.
There were multiple other cases of placing the mouse between screens at
the start of tests. It seems to be all copy paste.
Only maximise and pointerConstraints were failing before this, but we
may as well fix all of them.
Night Color adjusts the color temperature based on the current time in
your location. It's not a generic color correction module per se.
We need a central component that can be used by both night color and
colord integration to tweak gamma ramps and which will be able to
resolve conflicts between the two. The Night Color manager cannot be
such a thing because of its very specific usecase.
This change converts Night Color into a plugin to prepare some space for
such a component.
The tricky part is that the dbus api of Night Color has "ColorCorrect"
in its name. I'm afraid we cannot do that much about it without breaking
API compatibility.
A plugin may need to access kwinApp() or kwinApp()->platform() during
tear down, but the problem is that plugins are destroyed after the
kwinApp() object. The plugin manager must be destroyed explicitly while
the application is still valid to ensure that no crash will occur
during compositor teardown.
xdgshell allows clients to specify which output should we fill on
set_fullscreen. This change takes this request into consideration
instead of ignoring it.
The scripting api is not suitable for implementing all features that
should not be implemented in libkwin. For example, the krunner
integration or screencasting are the things that don't belong to be
compiled right into kwin and yet we don't have any other choice.
This change introduces a quick and dirty plugin infrastructure that
can be used to implement things such as colord integration, krunner
integration, etc.
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.
On Wayland, a surface must be displayed the same way no matter how the
attached buffer is transformed. In order to guarantee that, we build the
surface-to-buffer matrix, which is used to compute the texture coords.
The surface-to-buffer matrix represents an affine transformation. Thus,
performing linear interpolation between texture coordinates won't end up
in corrupted rendered results. This is the main assumption that we make
during generation of contents window quads. After creating a sub-quad,
the new quad's texture coordinates are computed by interpolating between
the source quad's texture coords.
However, WindowQuad::makeSubQuad() makes a concrete assumption about the
order of texture coords, which might be false if the attached wayland
buffer is rotated 90 or 270 degrees.
This issue went unnoticed after merging the viewporter patches because
the developer who was working on it had been using primarily nested
kwin_wayland for testing purposes. And it appears like kwin schedules
full screen repaints even though it supports buffer age. It still needs
some investigation why that happens.
BUG: 428003
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.
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
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.
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.
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.
We send two async actions via another process
We do a wait for one
We check that we received two events
This is racey. QTRY_COMPARE can allow both events to arrive separately.
Currently in order to load an Xcursor theme, kwin uses libwayland api,
which looks really awkward because of the way how the compositor talks
to itself via the internal connection.
The main motivation behind this change is to limit the usage of kwayland
client api in kwin.
Currently the only way for a uuser to invoke corner-tiling is to
manually set shortcuts for them. This patch adds another option: invoke
the existing shortcuts for edge tiling in a combined manner in quick
succession.
For example, hitting Meta+Left and then Meta+Up within a one-second
period will tile the active window into the top left corner. In practice
you hold down the Meta key and then press Left then Up (or Up and then
Left), and I think it feels very natural. Linux Mint's window manager
has this feature and I always missed it when I left Mint for the KDE
world.
Autotests for existing tiling shortcuts are adjusted to not break, and
additional tests for the new tiling options are added.
There are several ways to handle unmapping of a wl_surface. The first
one is to destroy the associated AbstractClient instance. The second one
is to transition the AbstractClient in a special state.
The problem with the second approach is that it makes animations such as
fade out more difficult to handle since effects in kwin are geared more
towards the first approach (destroying AbstractClient).
Summary:
This change splits the XdgShellClient class to better match existing
abstractions in the xdg-shell protocol and fix a few issues related to
sending configure events.
In the new client classes, configure events are handled differently.
Instead of blocking configure events, we try to send them as late as
possible. Delaying configure events will let us merge changeMaximize()
for X11 clients and Wayland clients and it also fixes the bug where
we don't send the final configure event when user has finished resizing
a window.
Given that configure events are not sent immediately, XdgSurfaceClient
keeps the last requested frame geometry and the last requested client
geometry.
This patch doesn't intend to fix all issues in kwin's implementation of
the xdg-shell protocol. For example, we still handle surface unmapping
very poorly.
Test Plan: Tests pass.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27861
Summary: Alt + Left Click to move windows has a tendency to conflict with creative workflow apps. While Alt can be changed to Meta in KWin's settings, Alt + Left Click shortcuts often cannot be customized in apps. Rather than making every user who runs into this problem change their settings, we should change our default settings to improve KWin's default usability. The fact that Alt + Left Click to move windows is older does not matter. We are trying to use Meta for global/shell shortcuts anyway.
BUG: 399375
Test Plan: The relevant parts of the relevant tests pass. kwin-testInternalWindow fails, but for unrelated reasons that have something to do with XWayland.
Summary:
AbstractOutput::name() behaviour is changed so that it matches the X11
behaviour, showing an identifier like "HDMI-0".
XdgOutput.name is set to this name.
XdgOutput.description is currently set to the manufacturer name and
model, but it's not exposed to Qt so we probably don't care too much.
This should fix plasmashell changing applets when switching between X11
and wayland.
Test Plan:
Relevant unit test
I still need to run it on my laptop.
Reviewers: #kwin, #plasma, zzag
Reviewed By: #kwin, #plasma, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28230
Summary:
As is KWin only had 1 Cursor which was a singleton. This made it impossible for
us to properly implement the tablet (as in drawing tablets) support and show where
we're drawing.
This patch makes it possible to have different Cursors in KWin, it makes all the
current code still follow the mouse but the tablet can still render a cursor.
Test Plan: Tests pass, been using it and works as well as before but with beautiful tablet cursors.
Reviewers: #kwin, cblack, davidedmundson
Reviewed By: #kwin, cblack, davidedmundson
Subscribers: davidedmundson, cblack, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28155
Summary: Recent changes prevented it to build on KDE Neon.
Test Plan: Built it on Neon
Reviewers: #kwin, bshah, davidedmundson
Reviewed By: #kwin, bshah, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28511
Summary:
We build some objects several times which makes it uncomfortable to develop KWin
since every time we modify something a lot of things get rebuilt. This should
help a bit although it doesn't solve all the problems.
Test Plan: Builds, tests pass
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: davidedmundson, zzag, anthonyfieroni, iasensio, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28445
Summary:
Uses the tablet classes introduced in kwayland.
Depends on D26858
Test Plan:
Scratched my tablet with a magic stick and it did things depending on the pressure.
https://youtu.be/GGx0TlNJlzs
Reviewers: #kwin, #plasma, zzag, davidedmundson
Reviewed By: #kwin, #plasma, zzag, davidedmundson
Subscribers: davidedmundson, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26859
Summary:
xdg-shell stable has been around for quite a while. A quick analysis
showed that many distros ship GTK and Qt that support both xdg-shell
v6 and stable. Therefore, we can drop support for legacy v6 protocol.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: apol, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28118
Summary: The code contains duplicate includes.
Test Plan: Open the files from the patch
Reviewers: #kwin, apol
Reviewed By: apol
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D28048
Summary:
Currently, we have only one shell client type - XdgShellClient. We use
it when we are dealing with Wayland clients. But it isn't really a good
idea because we may need to support shell surfaces other than xdg-shell
ones, for example input panel surfaces.
In order to make kwin more extensible, this change replaces all usages
of the XdgShellClient class with the AbstractClient class.
Test Plan: Existing tests pass.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27778
Summary:
Since Qt::KeypadModifier is set only for keypad keys and not the NumLock
key, we need to press at least one keypad key to determine whether
numlock is actually on. On the other hand, we know that when numlock is
on, the corresponding LED is also on. So we could check the LED rather
than press two keys.
Test Plan: testKeyboardLayout passes.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D27789
Summary:
This functionality will instead be implemented in KScreen such that manual and
automatic output rotation can be used and configured through a single UI in
unison together.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin, bshah, davidedmundson, zzag
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26036
Summary:
Currently, there are a couple of issues with sizeForClientSize(). First
of all, we have a method called clientSizeToFrameSize() which does similar
thing except applying geometry constraints and checking window rules. The
other issue is that sizeForClientSize() is doing a bit too much, it checks
window rules, it applies a bunch of geometry constrains. Sometimes it
does not perform conversion between client sizes and frame sizes!
This change attempts to address those issues by replacing sizeForClientSize
with two similar methods and changing semantics of some methods of the
X11Client class.
The most significant difference between sizeForClientSize() and the new
methods is that neither constrainClientSize() nor constrainFrameSize()
check window rules. This is up to users of those methods. In many places,
we don't have to check window rules because we check isResizable(),
which returns false if the frame size is enforced by a window rule.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D26828
