testLockScreen uses !eventSpy.wait() expression to check whether the
given signal is emitted. QSignalSpy::wait()'s default timeout is 5s,
which is too much. We don't need to wait that much, in fact, even
wl_display_sync() would suffice. In either case, let's pass explicit
timeout of 10ms which should be good enough.
Before
Executed in 60.49 secs fish external
usr time 3.92 secs 1.03 millis 3.92 secs
sys time 2.29 secs 0.16 millis 2.29 secs
After
Executed in 19.38 secs fish external
usr time 1.64 secs 347.00 micros 1.64 secs
sys time 1.15 secs 54.00 micros 1.15 secs
We need to monitor whether the inhibitorActive signal gets emitted. It
reduces the test's execution time from about 5 seconds to a couple
milliseconds.
There are cases where GLVertexBuffer::map will return null (as seen in
kwinglutils.cpp:1816) which does happen (as seen in the backtrace of bug
462017)
Make sure we don't call the null map in that case.
BUG: 372305
In this branch a new animation is being started, so a ref-guard needs
to be the same as in the similar branch for starting minimize animation
in the slot above.
The prototype of OutputLayer::endFrame() looks as follows
virtual bool endFrame(const QRegion &renderedRegion, const QRegion &damagedRegion) = 0;
On the other hand, qpainter output layers use a different order in the
header file and the cpp file.
Virtual backend is used primarily by tests, there are plans to use it
for virtual outputs too. But in either case we don't need screenshots.
I also can't imagine how it can be useful as a debugging tool. It's more
convenient to spin a windowed kwin instance.
The main motivation behind this change is to get rid of custom code in
virtual output layers and simplify it a bit more.
All the other backends present their surface regardless.
If the surface isn't presented, the scheduled frame is never
finished, and rendering gets stuck indefinitely.
This is also consistent with x11 standalone backend
which forgoes this check.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
WindowPaintData contains two projection matrices -
screenProjectionMatrix and projectionMatrix. I'm not sure why we have
two.
screenProjectionMatrix is initialized by the scene. While
projectionMatrix is usually updated by the effects. The two are not in
sync.
On the other hand, OffscreenEffect takes into account only
screenProjectionMatrix. It means that if a window is transformed by two
offscreen effects, the final result is going to be broken because
an OffscreenEffect must use the projection matrix specified by another
OffscreenEffect, which it doesn't.
This change cleans up projection matrix properties in WindowPaintData,
so there's only one projection matrix property. With that, offscreen
effects can be properly nested.
BUG: 462876
The window rules KCM calls this "No titlebar and frame", but different
less user-friendly terminology is used for the context menu action and
the global action. Let's unify them using the more user-friendly name.
BUG: 464007
FIXED-IN: 5.27
The focus outline that highlights the active virtual desktop in the Overview effect, as
well as the half-transparent outlines that are around the other virtual desktops, cover
2 pixels on every side of every virtual desktop thumbnail.
This is because an invisible rectangle is used that has the same size as the thumbnail
and has a colored border, but borders are always drawn on the inside of QML rectangles,
so content in the thumbnail is covered up. Therefore, the width of the rectangle has to
be slightly adjusted to account for the thickness of the border.
BUG: 450963
FIXED-IN: 5.27
Since kwin play with CAP_SYS_NICE, secure_getenv will fail for xkbcommon
to load user level xkbmap. This allows kwin to load config under
~/.config/xkb
BUG: 447206
There are effects that are mutually exclusive, e.g. magnifier and zoom.
They both use the same global shortcuts.
When switching from zoom to magnifier, the zoom effect must be unloaded
first, then the magnifier effect can be loaded. Doing so in the opposite
order will break global shortcuts in the magnifier effect because
zooming shortcuts are still bound by the zoom effect.
BUG: 457800
Right now this is marked as critical, but it's not a critical error.
Make it a debug to avoid spamming logs with not-very-actionable
information.
BUG: 463259
FIXED-IN: 5.27
A touch device could have no output object assigned due to the screen
being disabled, queued events or malconfiguration.
Using output would crash. Touch up is guarded so that we have matching
pairs.
BUG: 463385
By default translations are loaded from /usr/share/locale. This works fine for builtin effects
since we install our translations there.
However, it doesn't work for third-party scripted effects. They only provide a kpackage and can't
install anything to /usr/share/.
This patch allows them to ship translations in contents/locale/$language/LC_MESSAGES/$domain.mo,
where $domain is the X-KWin-Config-TranslationDomain metadata value
This matches what Plasma does for applets since https://phabricator.kde.org/D5209
CCBUG: 317338
Startup notifications optionally contain the target desktop the app should be launched to.
If present the window is sent to that desktop, if not it is sent to the current desktop.
Later in Workspace::activateWindow we check if the window is on the current desktop, and if not
we either move it to the current desktop or switch to the window's desktop depending on user preference.
However, this is broken because the window was already moved to the current desktop. To avoid this
only move the window if specifically requested by the startup id.
BUG: 462996
SurfaceInterface::scaleOverride() doesn't scale the bufferScale, so if the
scale override is 2, but the buffer scale specified by the client is 1,
bufferScale() will return 1.
Xwayland cursor surface implicitly relied on this behavior.
Porting cursor to SurfaceItem changed that. Now cursor surfaces honor
the scale override, which makes Xwayland cursors too small.
In order to properly fix, plasma has to scale Xcursor.size in xrdb. The
problem is that plasma also sets XCURSOR_THEME and XCURSOR_SIZE envvars
that take precedence. Plasma must stop setting those envvars, but it's
doable only with Qt 6.5, which got MouseCursorTheme and MouseCursorSize
hints in QPlatformTheme.
RootTile is a CustomTile and it has no parent because it's the root.
Therefore the sender object in connect() will be null and it's going to
produce a warning.
While not technically fitting for the name of the option, the behavior is what a user
would expect and it also matches with X11 (where the cursor goes to the touch position).
Prior to beb6cca65d, the drm backend used
to specify QRect(0, 0, modeSize.width(), modeSize.height()) CRTC rect,
so we didn't have to care about buffer transforms, but now that we
compute the CRTC rect from the buffer size, we have to take the buffer
transform into account.
It fixes squashed output contents when the output is rotated 90 or 270
degrees and it uses hardware transforms.
Scene::Window::discardPixmap() used not to add damage. No idea how it
got in SurfaceItem::discardPixmap(). Perhaps a mishap when introducing
window items.
From logical point of view, adding damage when discard a pixmap is not
necessary too because a new pixmap is going to be created.
The cursor scene contains the contents of the cursor. It contains a
CursorItem. The CursorItem either creates a SurfaceItem or an ImageItem
based on the currently attached CursorSource.
The cursor item is rendered by the cursor scene. For now, wherever the
cursor must be rendered, a dummy scene delegate is constructed. It's not
nice but it's a pretty cheap operation. There's a lot of potential for
clean up by moving cursor layer handling from output backends to
compositor. The main reason why there are no persistent scene views is
that it's just easier than tracking when they are actually used, e.g.
after switching between hw and sw cursor.
The software cursor fallback is a bit tricky case. It made to work by
constructing a scratch fbo. The cursor scene is rendered in the scratch
fbo, which is then rendered on the screen. Similar to the case above,
there's space for improvements, but I don't think it has to block the
effort for reusing Items to render the cursor.
