Summary:
If the format of the framebuffer is BGR we cannot create an RGB image
format from it - the rendering is incorrect. Unfortunately QImage does
not support a BGR image format.
To solve this problem we still use an RGB image format but on rendering
the front buffer is rgbSwapped to convert the RGB image to a BGR image.
BUG: 365243
FIXED-IN: 5.7.2
Test Plan: Tested on a neon kvm
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2134
Summary:
Our Wayland compositors cannot composite an X11 pixmap. Thus even
if we succeed in creating the pixmap, the changes would not get to
the scene. The code allowed for situation where a surface is not yet
set to fall back to the X11 code path. This can happen for XWayland
windows.
Test Plan: Crash in xclipboardsynctest without the change
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2010
Summary:
No need to delegate the painting of the software cursor into the backend.
The core has enough information to perform the rendering itself.
This change means less code duplication and all platforms which might use
a software cursor in QPainter compositor gain support for it without any
further adjustments.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2028
Summary:
The call to render the cursor was missing in the multi-screen code path
of the QPainter Compositor.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2027
Summary:
So far the drm platform did not verify whether creating and mapping a
DrmBuffer for a cursor works. This could result in a crash in the worst
case.
This change verfies whether mapping the two cursor buffers works, if
not software cursor is enabled. The code is adjusted to ensure that
none of the cursor buffers is accessed in case software cursor are
enabled.
Please note that right now the drm platform's rendering does not
support software cursors. Thus currently this change results in no
cursor at all. This will be addressed by following patches.
BUG: 364740
FIXED-IN: 5.7
Test Plan:
Verfied that it properly falls back to software cursor,
but could not verify that the crash is actually fixed.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2026
Summary:
Platform::setSoftWareCursor creates connections to the Cursor in order
to trigger repaints whenever the cursor position changes. The Cursor is
created before Platform::init is called, but after the Platform is
created. Thus the call needs to happen in init, otherwise the cursor
is not rendered correctly.
BUG: 356328
FIXED-IN: 5.7.0
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2025
Summary:
On the framebuffer backend the software rendered cursor was creating
rendering artifacts due to incorrect clipping. This change ensures that
in a single screen setup the clipping is performed correctly. For multi
screen a similar change might be required, but we currently don't have
any a way to test that as framebuffer only supports one screen and other
(visual) platforms don't support the software cursor.
CCBUG: 356328
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2024
On Wayland tear down the Workspace gets destroyed before the Compositor
gets destroyed. If the timer fires in that area, the Compositor would
crash. It's not possible to start the timer if the Workspace is
destroyed, thus it should also be stoped on Workspace destroy.
Reviewed-By: Bhushan Shah
Summary:
When the cursor changes the old and the new cursor geometry needs to
be repainted. Also when the cursor image changes a repaint of old and
new geometry is needed.
To support this the current cursor geometry is tracked instead of just
the cursor position. From the cursor position it's not possible to get
to the cursor geometry once the cursor image or hotspot changes, thus
the complete geometry needs tracking.
CCBUG: 356328
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2023
Summary:
For XWayland windows the window might be activated before the Wayland
Surface is set for it. Thus the keyboard focus is not passed to the
window. Only on the next activate after the window got created the
window got keyboard focus.
This change addresses this problem by emitting a signal from Toplevel
when the surface changes. The KeyboardInput listens to this signal
for the active client and updates keyboard focus again if the surface
changes. Thus keyboard focus is properly passed to XWayland windows.
Test Plan:
Test case which creates an X11 window is adjusted to verify
the condition.
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2009
Summary:
kwin_wayland disables ptrace on itself. This has the side effect of
core dumps no longer be created - which we want as DrKonqi doesn't
work for kwin_wayland.
This change introduces a dedicated signal handler for abort and
segfault. The signal handler enables ptrace again, unsets itself as
signal handler and raises the signal again, so that the proper crash,
abort handling can be performed.
Test Plan:
Added a crash, added an abort and verified that coredumpctl
shows the expected coredump.
Reviewers: #plasma_on_wayland, #kwin, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2003
Summary:
With the NoBorder option set the DecorationBridge won't create
decorations. Thus we get a nullptr and obviously should not call
into it. There was already a check for whether decoration is null,
so that is a rather embarrassing bug.
Test Plan: Test case added which exposes the crash
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1980
windowPixmap() is allowed to return a nullptr, thus we need to verify
that the returned pointer is not null. If it is null it's the same as
if there are no child WindowPixmaps.
Summary:
Plasma's OSD windows were stealing focus on Wayland. We can be sure
that they should not get keyboard focus, so a check to acceptsFocus
is added.
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1927
Summary:
If the ShellSurface gets destroyed while a decoration repaint is pending,
it is possible that on tear down the decoration calls into
ShellClient::caption. This used to call into ShellSurfaceInterface::title
which accesses a d-ptr which is already destroyed at that point.
This change caches the caption instead of delegating to ShellSurface,
just like almost everything else caches. Thus the tear down cannot access
invalid memory.
Once we can depend on Frameworks 5.24, we should also make sure to
connect to the new Resource::unbound signal to be able to handle tear
down prior to the object being completely deleted.
Test Plan:
Unfortunately no test case as this depends on phase-of-moon
aligning of destruction of the interfaces
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1913
I noticed that the GetActive call fails with an "Object path cannot be empty" error
when stealing that code for PowerDevil.
Differential Revision: https://phabricator.kde.org/D1910
Summary:
When a ShellClient gets unmapped and mapped again the signal windowShown
gets emitted. We need to handle this in Workspace to ensure the window
is in the proper layer and gets focus.
This fixes applications like KRunner/Yakuake not having focus on a
second show. Unfortunately it also brings back the problem that
notifiations steal focus (this needs to be fixed by passing a proper
window type to a notification).
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1864
Summary:
The checks in Client::adjustedClientArea were a little bit too
agressive, excluding also valid setups.
This change addresses the regression by keeping the actual intended
improvements in place.
The check in Client::adjustedClientArea is now only done for the
special case of desktopArea == area. This ensures that a strut excluding
a complete screen won't affect the overall workarea.
In addition new checks are introduced in Workspace::updateClientArea.
When calculating the new sareas a check is performed whether the
intersection with the adjustedClientArea would result in the sarea
becoming empty (thus a screen being completely removed). If that's the
case the geometry is ignored to not exclude a complete screen.
Interestingly I should have noticed that something with the logic is
odd. As the test case had two commented geometries which we now get.
BUG: 363804
Reviewers: #plasma, apol, lbeltrame
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1744
Summary:
When we get a configuration request, we also need to update the global
position on the DrmOutput, otherwise Wayland will know about the new
position, but KWin internally does not.
In addition we also need to trigger the changed signal on KWin::Screens,
so that internally code can react on the change.
With this change configuring layout of connected screens in KScreen
does work also in KWin.
Reviewers: #kwin, #plasma_on_wayland, sebas
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1858
Summary:
To use eglCreateImageKhr for an X11 pixmap we need an EGLDisplay created
for the same XDisplay as the X11 pixmap. This means if we created an
EGLDisplay for a GBM device, we are not allowed to load a texture from
the X11 pixmap and can result in a crash in the driver.
Similar in the nested X11 setup the EGLDisplay is created for the
rendering window, but the X11 pixmaps are from the Xwayland server KWin
started. They don't belong to the same windowing system.
This change addresses this problem by moving the loading of X11 pixmaps
from AbstractEglTexture to EglTexture of the EglOnX11Backend. Thus for
any usage on a non X11 platform we cannot hit the code path any more.
In addition the nested X11 platform can indicate that it doesn't support
it and thus also doesn't go through the code path.
Test Plan: Tested standalone and nested X11 platform
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1857
Summary:
For an X11 window through Xwayland KWin gets a client message with the
Surface id. KWin has two code paths for handling that:
* Wayland Surface is created after the X11 event
* Wayland Surface is created before the X11 event
In the first code path in WaylandServer KWin called Toplevel::setSurface,
the other code path just updated the m_surface without calling into
setSurface. This means the connects for the Surface were not set up,
resulting in the worst case in accessing deleted memory after the Surface
was destroyed.
This change now ensures that setSurface is called from both code paths.
That should fix the potential crash and could also be a fix to the
problem that sometimes X windows seem to not be damaged correctly.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1820
Summary:
When managing a new decorated ShellClient we observed that the window
gets placed with a wrong geometry and on next damage event expands into
a strutted area.
The main reason for this behavior is that the window geometry did not
get updated when creating the decoration. With this change the geometry
gets updated, so that the placement is performed on the correct geometry.
The change itself does not yet cover all conditions. E.g. a maximized
windows which will get decorations will be incorrectly sized. This
requires further changes.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1812
Summary:
The idea is to not send multiple resize requests to a client when we
know that we might have multiple geometry changes. E.g. when going
from maximized to restored the borders change and trigger a resize in
addition to the resize from switching to restored.
The implementation is inspired by the GeometryUpdateBlocker.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1808
Summary:
This ensures that we don't send a size request with the borders still
added.
Test Plan:
Verified that a maximized window is properly sized and
doesn't have empty borders
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1807
Summary:
When a shell client got mapped, unmapped and mapped again we emitted
the shellClientAdded signal in WaylandServer again. This resulted in
e.g. Workspace, EffectsHandler, etc. to start managing the window again.
This can be a reason for problems we see with such windows like the
Plasma panel dialog when opened the second time.
Test Plan:
Needs extensive testing on real world system as that changes
behavior now.
Reviewers: #kwin, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D1784
Summary:
Using a static XRenderPicture results in a crash on exit as for cleanup
the already destroyed xcb_connection_t* is required.
This change ensures that the static XRenderPicture gets destroyed in the
static cleanup handler for SceneXRender::Window.
CCBUG: 363251
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1733
Summary:
The method xRenderBlendPicture created a static XRenderPicture on
first usage. To cleanup a XRenderPicture an xcb_connection_t* is needed.
As it's static the cleanup happens on exit handler and at that time Qt
already destroyed the xcb_connection_t*. With a certain chance this will
crash.
To expose the problem a Q_ASSERT(qApp) is added in the destructor of
XRenderPicture. Using xrenderBlendPicture() will hit this assert on
application exit. This is demonstrated by the added auto test.
The actual fix to the problem is moving the static variable out of
the method and introduce a global cleanup method just like the init
method. This is now called from Workspace dtor, so before application
goes down.
CCBUG: 363251
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1731
Summary:
This ensures that resizing a panel updates the client area. On X11 there
is an event when the struts change, but on Wayland the struts are implied
from window type (panel) and the panel behavior, so we need to trigger it
manually.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1811
Summary:
The implementation was broken as it transformed the QRects into QRegions,
subtracted the geometries and took the bounding rect again. In several
setups this could result in the strut getting ignored.
This change improves the calculation of the struts by creating a QMargin
which describes the area which needs to be subtracted from a screen rect.
The QMargin is only adjusted for the edge the window borders. We can
assume that a window with a strut needs to border a screen on Wayland.
With this change we are also able to support panels between screens.
On Wayland a panel placed on the right of a left screen affects the
maximization area of the left screen, but does not affect the overall
workarea.
CCBUG: 167852
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1803
This is an update to c95ddb7102 and
implements the emit of maximized changed in deocration like on Client.
Overall the code looks like it should be merge better together with
Client.
Reviewed-By: kbroulik
Summary:
From the famous category: "How could that code ever have worked".
Maximized state changes were never passed to window decorations. For
X11 windows the decoration updated the state nevertheless, for Wayland
windows the state did not get updated, thus a maximized window had
borders and was shown with a not maximized button.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1805
Summary:
This change addresses the problem of the incorrectly rendered shadows
when opening a window (e.g. Kickoff) a second time. In case of e.g.
Kickoff not all elements are set, thus e.g. left might be 0, but right
has a value. So for calculating the height the maximum of the values
must be used.
Test Plan: Opened Kickoff and systray a few times
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1792
Summary:
The problem of the badly rendered shadows in case of opening kickoff
twice on Wayland is related to this. In that situation both the
width and height are 0. The rendering to the image fails and creating
the texture fails. This causes the flickering we see during rendering.
This change now discards such a shadow with an invalid size. This is
not fixing the actual problem of the shadow, but rather the symptom.
Nevertheless it's an important change as it makes it at least not
look fully broken.
Reviewers: #kwin, #plasma_on_wayland
Differential Revision: https://phabricator.kde.org/D1790
The added test exposes the problem that a shell surface might request
being maximized and then provide an incorrectly sized buffer. In this
case the ShellClient is incorrectly considered as maximized.
I don't have a good idea how to address this yet, but still publish
the test case exposing the problem.
Summary:
So far destroyWindowManagementInterface was only called when the
ShellClient got unmapped. But it's possible (although not recommended)
to just destroy the Surface without prior unmapping. In that case the
PlasmaWindow got leaked.
This change addresses this problem by always calling
destroyWindowManagementInterface from ShellClient::destroyClient.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1762
Summary:
If a PlasmaShellSurface is a Desktop, a Panel or an OSD it implies
that the window is on all desktop. So let's set it like that.
Test Plan: Auto test added and also confirmed by manual testing
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1747
Martin Gräßlin
Jonathan Riddell
David Edmundson
l10n daemon script
Andreas Hartmetz
Kai Uwe Broulik
David Fort