Summary:
If KWin fails to start the Wayland server due to XDG_RUNTIME_DIR not
being set, kwin_wayland should terminate with an error condition but
not crash.
This change makes sure that KWin detects that the Wayland server does
not work and terminates the startup early and ensures that it doesn't
crash while going down.
An error message is shown that we could not create the Wayland server.
Test Plan:
Test case added which verifies that WaylandServer fails to
init. Manual testing that kwin_wayland exits with error 1.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2078
Summary:
We need to properly tear down the application - this can be achieved
through QCoreApplication::exit. Otherwise there is a chance that the
cleanup handling crashes.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2136
Summary:
If it's not possible to create a buffer to blank the output, KWin won't
be able to render to the output. In that case the output should not be
added to the list of outputs.
To support this DrmOutput::blank and DrmOutput::init return bool to
indicate whether they succeeded. DrmBackend handles this situation and
doesn't add the output to the list of outputs if init failed.
If after init there are no outputs KWin is in a state where it won't
be functional. Thus the platform emits the initFailed signal to
terminate.
BUG: 365242
FIXED-IN: 5.7.2
Test Plan: No hardware to reproduce the condition
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2135
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
The struts test is extended by a setup containing two horizontal
screens, bottom aligned with the left screen smaller than the right.
Thus there is a dead area in the top left corner. In addition there's
a panel on top left screen.
Apparently KWin allowed windows to open in the dead area. The test
case reconstructs this by opening a window with the same size hints,
but in the test it's working correctly.
A few more cases where we need to ensure that the created window is
destroyed before going into next test method.
Interesting observation: the generated window ids are identical.
Possible problem with KWayland::ClientConnection?
New test method which verifies that a newly mapped window is rendered
correctly, that cursor image set on it is rendered correctly, also when
pointer moves.
Summary:
Many tests create a Wayland window, render it and then wait till it's
created in KWin as a ShellClient. To reduce code duplication the test
helper provides helper methods to wait for the next ShellClient to be
shown and to directly render and wait for the window for that to be
shown.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2057
Summary:
A new namespace KWin::Test is added which provides a few helper
functions. It makes it easy to setup a KWayland client connection with
the base set to be able to create a Surface and flags to create
additional interfaces. This replaces the KWayland connection dance in
init() methods. For cleanup() there is also a dedicated helper function.
In addition there are helper functions to:
* render a surface
* create a surface
* create a shell surface
* flush the wayland client connection
* access to the created interfaces - for compatibility with existing code
The idea is to extend this Test library also for other common use cases
like creating an X11 connection and X11 windows, etc.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2053
Summary:
A dedicated cmake function is added to create a test case. It takes
a NAME, the SRCS and additional LIBS.
Thus it's
integrationTest(NAME myTestCase SRCS test.cpp)
to create a standard integration test.
In addition kwin_wayland_test.cpp is compiled into a static library
to decrease the compile time a little bit.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2052
Summary:
The idea behind this autotest is inspired by bug 356328 which produced
incorrect rendering results. Also it's inspired by openQA which performs
image reference comparisons.
This test case tries to go further. It creates reference images which
must match the rendering result exactly. So far the test case verifies
the start condition - kwin started and one frame is rendered with default
cursor in the middle of the screen. And it verifies the moving of the
cursor without any windows shown. Whenever the cursor moves a repaint
should be triggered and the old and new area should be properly
repainted.
To support this the test needs some minor changes in KWin:
* Scene provides a frameRendered signal - needed for waiting on frame
* Scene and SceneQPainter are exported
* SceneQPainter provides access to it's Backend, so that we get to the
backbuffer
* ScriptedEffectLoader is exported for getting a list of all scripted
effects - (we don't want fade to manipulate the rendering)
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2046
One needs to call ConnectionThread::setSocketFd in order to not have it
connect through the normal socket.
As WAYLAND_SOCKET is set the implementation would call the correct
functionality anyway. This change only ensures that no wrong debug
message gets logged.
Test was failing on build.kde.org, though passing locally. This change
tries to make the test more robust to timing issues which makes it
hopefully pass on build.kde.org again.
The id we internally have is a signed int and might be negative, but
the touch id we get is unsigned. We can savely cast the unsigned to
signed as touch ids are recycled and more than 10 touch points is
unlikely to be useful.
Summary:
It's mapped to be on all desktops in order to properly have tooltips
show for the panel (which is on all desktops) instead of just on the
desktop it's created.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2032
Summary:
The clipboard sync is done by a dedicated helper binary launched by
KWin. This helper binary is forced to xcb platform to piggy-back on
Qt's implementation of the X11 clipboard. In addition it implements
the Wayland clipboard - which is much simpler. Reading the Wayland
clipboard is based on the implementation in QtWayland.
KWin internally knows the DataDeviceInterface belonging to the helper
application. Whenever an xwayland client is focussed, this DataDevice
is allowed to set the selection and KWin manually updates the current
selection in the SeatInterface. By that the sync from X11 to Wayland
is implemented. When afterwards a Wayland client is selected, it's sent
the current selection which references the X clipboard and a data
transfer can be initiated in the normal Wayland way.
For the other direction KWin sends the current selection to the helper's
DataDevice whenever an xwayland window is focused. The helper application
reads the Wayland clipboard and sets it on the X11 clipboard. Thus the
Wayland clipboard is synced to X11.
The approach used here will also be useful for implementing a clipboard
manager (aka klipper).
Currently the implementation is not yet fully completed. We need to
make sure that the helper application gets restarted in case of a crash.
Test Plan: See added test case
Reviewers: #plasma_on_wayland, #kwin
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D1973
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
This testcase tries to emulate the panel setup on the phone,
- Window placement strategy is set to maximizing
- Top panel with height of 60
- Bottom panel with height of 150
However this is still not complete testcase, some todo items:
- Create Plasmashell desktop window before creating panels
- Create normal window and verify if its placement/position is right
Reviewed-by: Martin Gräßlin <mgraesslin@kde.org>
