Summary:
Currently, when resizing a window the cursor doesn't match the resize
direction. The reason for that is the move-resize cursor is hardcoded.
To fix that, CursorImage::updateMoveResize has to use AbstractClient::cursor.
Also, because the move-resize cursor is updated after calling startMoveResize,
we have to connect to AbstractClient::moveResizeCursorChanged.
BUG: 370339
FIXED-IN: 5.15
Reviewers: #kwin, davidedmundson, broulik, romangg, graesslin
Reviewed By: #kwin, graesslin
Subscribers: davidedmundson, romangg, graesslin, kwin
Tags: #kwin
Maniphest Tasks: T5714
Differential Revision: https://phabricator.kde.org/D3202
Summary:
This patch aims at improving the Toplevel, internal window and decoration
focus tracking.
In detail the goals are:
* Clean tracking of beneath and focus Toplevel as well as decoration and
internal windows. Splitting this up in well defined sub routines.
* Minimal find Toplevel operations on window stack.
* Reduce code duplication in pointer and touch child classes.
* Reuse tracking in drag operations.
* Allow direct usage of Wayland input interfaces for decoration and internal
windows in the future.
* Update touch focus on external events like VD switches correctly.
Test Plan: Manually and existing autotests.
Reviewers: #kwin
Subscribers: kwin, zzag
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15595
Summary:
Same is done on X11 (see Client::updateMouseGrab), so we should have this
on Wayland as well.
Also adding the pointer confinement restriction for modifier + wheel.
Test Plan: Run new and adjusted testcases with and without the change
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16025
Summary:
If the new pointer position is "off screen", PointerInputRedirection
just ignores that new position. So, pointer remains on its previous
position. In some particular cases, like reaching default panel, it
degrades desktop experience because one have to slowly move pointer in
order to reach what he/she wants.
This change addresses that problem by confining the new pointer position
to screen geometry.
BUG: 374867
FIXED-IN: 5.13.4
Test Plan: Ran tests
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14036
Summary:
It will then be renderered appropriately when painting to the output
buffer.
Test Plan: Updated unit test, plus used with other relevant patches
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13606
Summary:
From Wayland documentation:
"When a seat's focus enters a surface, the pointer image is undefined and
a client should respond to this event by setting an appropriate pointer
image with the set_cursor request."
KWin's interpretation so far for the undefined pointer image was to
remove the pointer image when entering a surface waiting for the client
to set a cursor image. This can result in a short flicker as there might
be a frame without a cursor image.
This patch changes the behavior by keeping the previous image till the
application set a new one. This brings some advantages:
* if the application is not responding a cursor is still shown
* if the same cursor is used as in the previous window we don't have a
flicker
CCBUG: 393639
Test Plan: I cannot see the flicker, so only tested with the adjusted tests
Reviewers: #kwin, #plasma
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D12631
Summary:
This matches the DRM backend more closely and allows mid-test removal and
addition of virtual outputs with different properties in the future.
Test Plan: Before and after 93% tests passed.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: graesslin, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11351
Some distributions (e.g. Arch, FreeBSD) call the DMZ-White cursor theme
Vanilla-DMZ. Due to that our tests are failing even if the correct theme
is installed (see also T6623). This change tries to detect whether
DMZ-White is installed by looking into the GenericDataLocation. If not
found we set to Vanilla-DMZ. No guarantee that the check works for all
setups, but it's only tests...
D7460 in kwayland assumes all WL_SHM_FORMAT_ARGB8888 buffers have
opacity premultipied RGB values.
Kwin tests need updating to do the same.
Rendering code did not need changing.
Test Plan: Tests now pass
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7607
Summary:
During pointer motion we already had the condition that an update of
focused pointer surface can only happen when no button is pressed. But
there are more conditions where we try to update the focused pointer even
if a button is pressed. E.g. if the stacking order changes.
This happens when trying to move one of Qt's dock widgets:
1. Press inside a dock widget
2. Qt opens another window, which is underneath the cursor
3. KWin sends pointer leave to parent window
4. dock widget movement breaks
This change ensures that also this sequence works as expected and the
pointer gets only updated when there are no buttons pressed, no matter
from where we go into the update code path.
BUG: 372876
Test Plan: Dock widgets in Dolphin can be moved now.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5461
Summary:
So far the window decoration was not considered and e.g. right clicking
the window decoration resulted in two open popups - one by KWin and one
by the application. This change addresses the problem by ensuring the
popup gets cancelled if the decoration is clicked. It's considered not
being part of the window.
Test Plan: Added test case which fails without the change
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5388
Summary:
So far KWin did not properly handle popup windows. That is when a popup
surface got created and a click outside the surface happened KWin did not
send out the popupDone Wayland event.
This change makes KWin aware of whether a surface is a popup and tracks
through a new PopupInputFilter whether there are popup windows. In case
there are popups the new filter waits for mouse press events and cancels
the popups if the press does not happen on any surface belonging to the
same client. To quote the relevant section of the Wayland documentation:
The popup grab continues until the window is destroyed or a mouse
button is pressed in any other client's window. A click in any of the
client's surfaces is reported as normal, however, clicks in other
clients' surfaces will be discarded and trigger the callback.
So far the support is still incomplete. Not yet implemented are:
* support xdg_shell popup windows
* verifying whether the popup is allowed to be a popup
* cancel the popup on more global interactions like screen lock or
kwin effect
BUG: 366609
FIXED-IN: 5.10
Test Plan: Auto test and manual testing with QtWayland client
Reviewers: #plasma, #kwin
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5177
Summary:
Consider the following situation: we have three InputEventFilter linked
in the sequence A - B - C.
The input filters are processing pointer motion events. The expected
behavior is that the new motion is processed in the sequence
A -> B -> C
So far this did not work correctly if the pointer gets warped during the
processing. If e.g. filter B warps the pointer we get a motion sequence:
A (1) -> B (1) -> A (2) -> B (2) -> C (2) -> C (1)
The filters following the one warping the pointer get first the newer
than the older position. This is obviously wrong. Unfortunately it is not
just a theoretical condition, but a condition happening when interacting
with the screenedges, which warp the pointer.
This change introduces a PositionUpdateBlocker in
PointerInputRedirection::processMotion to ensure that a processMotion
call finishes prior to the next update. If the PositionUpdateBlocker is
blocked the new position gets scheduled and processed once the
PositionUpdateBlocker gets destroyed.
With this we get the expected sequence for B warping pointer:
A (1) -> B (1) -> C (1) -> A (2) -> B (2) -> C (2)
This should hopefully improve the interaction with screen edges on
Wayland.
CCBUG: 374867
Test Plan:
Added an auto test demonstrating the issue of incorrect
ordering caused by screenedges. Prior to the change the test is failing.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5182
Summary:
This is a preparation step for no longer creating a socket in the tests
and slightly simplifies the init test code.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3575
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:
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:
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
It's currently failing on build.kde.org. I'm not able to reproduce the
failure localy so I can only interpret the failure. The failure looks
like a window is still present in the next executed test case thus
breaking the positioning.
This change ensures that the window is properly gone before going into
the next test case.
It's currently failing on build.kde.org. I'm not able to reproduce the
failure localy so I can only interpret the failure. The failure looks
like a window is still present in the next executed test case thus
breaking the positioning.
This change ensures that the window is properly gone before going into
the next test case.
On build.kde.org we cannot use the breeze cursor theme. Instead we have
DMZ-White (debian package dmz-cursor-theme).
This change adjusts the PointerInput test to enforce DMZ-White and uses
SizeAllCursor instead of OpenHandCursor as that one seems to be missing
in that theme.
Hopefully with these changes the test starts to pass on build.kde.org.
Try to fix test on CI system. With neither a config nor the env variables
the cursor selection falls back to the default cursor theme, which might
not contain the cursors we need.
When starting effect mouse interception the current focused window
and or decoration should get a leave event. Similar when the effect mouse
interception ends the current pointer position needs to be evaluated and
a pointer enter be sent if needed.
The test case verifies that setting an override cursor during mouse
interception works and that it's also possible to change it. When
ending mouse interception the cursor image should be adjusted again.
The test shows that when mouse interception starts KWin should send
a pointer leave event to the current focused window and similar needs
to handle the stop of mouse interception.
Updating the focused pointer surface results in the cursor to change.
The CursorImage needs the current focused window to evaluate which cursor
to use, though. Thus we need to make sure that the window reflects the
current state before updating the seat.
This test case verifies that the cursor image and hot spot changes
correctly when focusing a window, changes when damaged and hides.
Test shows that when focusing a window the cursor image is not
removed, neither that unfocus sets back to fallback cursor properly.
Small regression: the command didn't get updated at all, so it was always
MouseNothing.
To prevent such a regression to sneak in again the change comes with
autotest for the action on inactive and active window.
Experimental testing in real world showed it's just a signing issue
in this specific case. The events passed to wayland clients scroll
in correct direction.
With that all the actions are implemented just like on X11.
There are two not yet implemented differences:
* hide splash window when clicking it
* replay event on special window
Implemented in the ForwardEventFilter: before forwarding the event
to the window we check whether a modifier is pressed and perform the
wheel command.
Possible improvements: each axis event triggers the same change, there
is no adjusted scaling.
This change implements the mouse command for modifier (alt/meta) plus
click in InputRedirection so that it also works on Wayland.
Modifier plus mouse wheel is not implemented yet.
For easier code in Options a new method is added which provides the
configured modifier as a Qt::KeyboardModifier instead of a Qt::Key code.
Test case is added which simulates all variants of modifiers plus
supported mouse buttons to trigger move.
The logic should not be tied to whether libinput is used. It's relevant
for all Wayland backends whether they use libinput or not.
In addition this should generate a pointer motion event, so that proper
processing can take place and we get proper pointer enter events.
The test removes the second screen while the cursor is on it. This
should warp the pointer to the center of first screen and trigger
a focus enter event.
As can be seen by the expect failures currently it's bound to libinput
and also doesn't process the event as if it were a pointer event.
If the pointer is warped the position change should be treated like
a change coming from the input device. Our normal processing should
take place.
A problem in this case is the timestamp to pass to the wayland server.
Normally our timestamps come from the backend/libinput and we don't
know the next one. As an intermediate solution we just use the last
timestamp on the seat. In future a solution could be to not use the
backend's timestamp at all, but have our own timestamp handling.
When warping a pointer through Cursor::setPos it should be processed
just like any other pointer event. It should generate enter/leave event,
create motion events, etc. This is currently not the case as the test
shows.
A new test case which ensures that when stacking order changes the
pointer focus gets re-evaluated and updated. I was positively surprised
to notice that this already works.
Noticed two other problems while writing the test case:
* warping pointer does not re-evaluate the pointer pos
* deleting a ShellSurface (client) does not destroy the ShellClient (server)
Vlad Zagorodniy
Roman Gilg
Martin Flöser
David Edmundson