Summary:
So far when KWin intercepted a key event a leave was not sent to the
Wayland surface currently having keyboard focus. This could result in
the Wayland application to start repeating keys. E.g.
1. application gets key press event
2. This triggers an internal window to show
3. key release goes to KWin internal window
4. application starts to repeat key as there is no release
With this change whenever KWin intercepts the key event e.g. due to
* internal window
* Effects grabbing key event
* Tabbox
the focused keyboard surface is set to null, thus triggering a leave
event and the client not starting to repeat the event.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2402
Summary:
A new method to tell the effects system whether the compositor scene
is able to drive animations. E.g. on software emulation (llvmpipe) it's
better to not do any animations at all.
This information can be used by effects to adjust their behavior, e.g.
PresentWindows could skip transitions or effects can use it in their
supported check to completely disable themselves.
As a first step all scripted effects are considered to be unsupported
if animations are not supported. They inherit AnimationEffect and are
all about driving animations.
The information whether animations are supported comes from the Scene.
It's implemented in the following way:
* XRender: animations are always supported
* QPainter: animations are never supported
* OpenGL: animations are supported, except for software emulation
In addition - for easier testing - there is a new env variable
KWIN_EFFECTS_FORCE_ANIMATIONS to overwrite the selection.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2386
Summary:
We need to call Workspace::clientHidden when minimizing. Otherwise
Workspace doesn't update the active client and the now minimized
window is still active.
BUG: 366634
Test Plan:
Test case works now and also tested in nested setup that
active window changes.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2410
Summary:
If the user clicked a pointer button or scrolled a pointer axis the
held modifier was most likely intended to modify the pointer event.
Thus the modifier only shortcut should not be triggered.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2435
If a pointer axis is scrolled while a modifier is hold, the modifier only
shortcuts should not trigger. The user wanted to use the modifier for the
pointer axis.
This is not implemented yet, thus all is QEXPECT_FAIL.
If a pointer button is pressed or gets pressed while a modifier is
hold, the modifier only shortcuts should not trigger. The user wanted
to use the modifier for the pointer button.
This is not implemented yet, thus all is QEXPECT_FAIL.
This test verifies the functionality of modifier only shortcut
activation. The base test case uses a helper object which is exported
to DBus and has a slot which can get triggered.
The test configures the individual modifiers to call that DBus method
when the shortcut is triggered. It simulates pressing the modifier and
verifies the DBus method was invoked or not.
client->isOnActivity("foo") will return true if the client is on no
activities, as that's the equivalent of saying we are on all activities.
In our case we do want to check activities() shows the right thing.
Verifies the condition from D1982 with expected_fail. That is sets
a Client on non existing activities and expects that it should be on
all activities.
Summary:
Plasmashell's desktop windows are RGBA which forces the compositor to
perform blending and render the background. That is absolutely pointless
as there is no window behind the desktop window it could blend to. All it
does is destroying KWin's more optimized code path and forcing additional
rendering which will never be visible (including shader push/pop).
With this change KWin forces desktop windows (both X11 and Wayland) to
be considered as opaque by setting the depth to 24. Thus blending is
disabled and the background is not rendered.
Test Plan:
Verified with apitrace that KWin goes in the opaque rendering
path for desktop windows.
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2382
Summary:
With this change KWin can create window decorations for internal windows.
Thus it's also possible to move internal windows and resize them which is
especially important for the debug console.
Reviewers: #kwin, #plasma_on_wayland, sebas
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2371
The test LockScreenTest::testPointerButton and testPointerAxis both
fail on Neon's CI infrastructure. In order to make the test more reliable
the tests first wait for the pointer enter after unlock before simulating
another button press.
So far KWin's pointer surface enter handling was:
1. update fouced surface
2. update the global position
On client side this resulted in:
1. Enter with incorrect coordinates
2. move event to correct coordinate
With QtWayland this results in the case of multiple surfaces in one
application that Qt doesn't properly process the enter event and the
Window never getting pointer focus and not reacting on any pointer
input events.
The root problem is that the KWayland server API is not ideal for
supporting this situation. There is an API call for setting the global
position (which causes a pointer motion for the focused surface) and
an API call to update the focused surface. But a combination for both
is (still) missing.
This change addresses the problem by first unsetting the entered surface,
then updating the global position and afterwards setting the new surface.
Thus the position is correct. While this needs to be made better in
KWayland, this is an urgency bug fix to get the behavior correct and thus
first working around the API deficit and not first extending in KWayland.
Reviewed-By: bshah
Summary:
This fixes a regression introduced with a1afeded6a.
The connections were setup every the windowShown signal got emitted.
This caused effects to get multiple singals and start multiple animations
which then do not get cancelled correctly.
The incorrect behavior was most visible in the translucency effect which
did not cancel the move animation and the window stayed translucent.
BUG: 366081
Test Plan:
New test case which simulates the behavior of the translucency
effect.
Reviewers: #kwin, #plasma, sebas
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2346
A new sub-directory scripting is added in autotests/integration to
gather all test cases related to scripting.
The first added test case verifies the activation of screen edges. For
that it loads a helper script, which reserves an edge based on config.
When the edge is triggered showing desktop is activated.
Summary:
This change ensures that KWin doesn't crash in the QPainter scene if
the compositor gets restarted and if there are Wayland clients.
BUG: 365471
Test Plan:
Test case added to scene qpainter which triggers a restart
of the Compositor with a window being shown. Verifies that rendering
is correct afterwards.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2185
Summary:
KWin needs to support restarting the OpenGL compositor in case of a
graphics reset event.
On Wayland the tricky part is that the applications should not notice
this. Most importantly KWin cannot just destroy the EGLDisplay and create
a new one. But this is how a restart works: the complete compositor gets
torn down and recreated - including the EGLDisplay.
This change moves ownership of the EGLDisplay to the Platform.
The AbstractEglBackend subclasses query the Platform whether there is
already an EGLDisplay. Only if there is no EGLDisplay the EGLDisplay is
created and only if no EGLDisplay is registered with Wayland the bind
is performed.
Another change is regarding the destruction: the AbstractEglDisplay does
no longer unbind the Wayland display and does no longer destroy the
EGLDisplay. The EGLDisplay is destroyed by the Platform - so very late
on application exit. The Wayland display is unbound when the Compositor
terminates.
Test Plan:
Limited testing with the added auto-test. This one needs to
be extended to fully verify that OpenGL applications continue to work.
But this requires build.kde.org to support OpenGL on Wayland.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2202
Summary:
Most platforms like the nested and virtual do not handle the outputs
themselves and WaylandServer announces the Outputs to Wayland.
So far this was static: at startup it got announced once to Wayland
and any changes were not catched.
This change makes WaylandServer listen to changes to the Screens and
sync them to Wayland.
Unfortunately KWin's internal Screen information is not sufficient to
properly synchronize this to Wayland and also Wayland by not supporting
adding/removing modes does not help.
Thus the solution implemented here is to add new outputs reflecting the
changes and then removing the old ones. This creates situations with more
outputs being present than actually there, but prevents that there are
no outputs at all.
Test Plan: Auto test added which verifies this for the virtual platform
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2233
Summary: Needed for e.g. the pager.
Test Plan: Test case for PlasmaWindow verifies the geometry
Reviewers: #kwin, #plasma_on_wayland, hein
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2200
Summary:
With this change auto-hiding panels are animated again by SlidingPopups
effect.
Test Plan: Test case adjusted, and tested in VM
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2157
BUG: 354407
FIXED-IN: 5.8.0
A test to simulate auto-hiding panels. Preparation step for making the
slidingpopups effect working again for auto-hiding panels.
The test case simulates creating a panel at the screen edge, hides it
through the property and shows it again through the edge.
Summary:
The WaylandServer creates the XdgShellV5 interface and hooks it up
to create a ShellSurface whenever an xdg surface or xdg popup is created.
ShellClient gains some new ctors for the different variants and is
adjusted to delegate to xdg surface respectively.
With this change KWin mostly supports xdg-shell protocol. Still missing
is support for the "geometry" request which is rather difficult to
implement in KWin.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2108
Summary:
This allows effects to animate when a window is shown again and when
a window gets hidden but not yet closed/destroyed. This situation
happens on X11 for e.g. auto hiding panels and on Wayland for pretty
much any window which properly unmaps (windowHidden) prior to destroy.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2084
Summary:
So far when a ShellClient got unmapped ready_for_painting was set to
false. That is the ShellClient was treated in the same way as a not
yet shown window. It was completely excluded from painting, a close
animation impossible.
This change makes use of the functionality available in
Client::hiddenInternal(). The window is considered as hidden, thus
still excluded from e.g. getting input events, but could be rendered
any time as we still have a previous window pixmap (if referenced).
This allows to have it considered in the rendering pass, but effects
still cannot make use of it as that state is not yet exposed to the
effects.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2083
Summary:
Have one dedicated method which performs the connection for both
Client and ShellClient. This fixes the desktopPresenceChanged signal
not being passed to the effects.
Note that not all signals are merged. Most signals setup for Client
don't make sense for ShellClient as ShellClient cannot block composite
or unredirect.
Test Plan:
Test case added for ShellClient to ensure that the signal
is correctly invoked on the ShellClient, Workspace and EffectsHandler.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2059
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
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
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.
