Summary:
This change implements forwarding the pointer gestures to the new API in
SeatInterface.
While screen is locked no gestures are forwarded to the server. Also
locking the screen cancels any active gesture. Similar if areas inside
KWin would start to intercept the gestures, they need to be cancelled on
the Wayland SeatInterface.
Test Plan: Not yet
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3174
Summary:
For whatever reason Qt scrolled the wrong way on internal windows. As a
new QWheelEvent is constructed anyway, just multiply by -1 to get the
direction fixed.
BUG: 371999
FIXED-IN: 5.8.4
Test Plan: Tried debug console in nested setup, scrolled correctly now.
Reviewers: #kwin, #plasma_on_wayland, broulik
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3247
Summary:
The Xkb implementation starts to track the state of the LEDs in the
keymap and emits a signal whenever the LEDs change. This signal is
connected to a method in LibInput::Connection which updates the led
state on all devices and uses it to init the state of the led when a new
device gets connected.
BUG: 369214
FIXED-IN: 5.8.2
Test Plan: Connected a keyboard with LEDs and enabled NumLock and ScrollLock.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2943
Summary:
If KWin interacts with Libinput the RelativePointerManager interface
gets created on the Wayland server. The ForwardInputEventFilter does
forward the relative motion events in addition to the normal motion
events.
In order to properly support the relative motion events as they are
expected by the Wayland protocol the handling of pointer motion events
got slightly adjusted:
* Libinput Pointer event extended by the additional data points
* Libinput Pointer event carries the delta as a QSizeF instead of
QPointF
* PointerInputRedirection adjusted to take a pointer motion event with
more arguments
* Custom QMouseEvent subclass adjusted to carry the additional members
The DebugConsole is adjusted to show the relative motion events in
addition to the global position.
Test Plan:
Verified the manager object is created and verified the
events in DebugConsole. Unfortunately not aware of any test application.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2979
Summary:
This change adds support for resizing outside the window decoration
(e.g. setting borders to NoSide or None).
To support this a new Toplevel::inputGeometry() -> QRect method is
added which exposes the geometry adjusted by the margins provided by
the decoration. This is checked in InputRedirection when finding a
Toplevel at a given position. The logic for figuring out whether the
event should go to the decoration or the window already handled the
situation correctly, so no further changes are needed.
BUG: 364607
FIXED-IN: 5.8.1
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2787
So far this method translated the keysym to Qt::Key. This is no longer
needed as the only method which invokes processKey has access to the
translated key. Thus saving one translation for every key press.
Reviewed-By: bshah
A new protected method is added to InputEventFilter to forward a
QKeyEvent to the Wayland server. Several input filters need to forward
the event to have a proper state of the events. E.g. the TabBox filter,
but also the internal window filter and effects filter. It's important
to update all events even if the events are not forwarded to a surface.
This new method takes care of the general handling like ignoring key
repeats, etc.
Reviewed-By: bshah
When Alt+(Shift)+Tab is grabbed we have the modifier press key being
passed to the Wayland server as key events are not yet grabbed. As KWin
grabbed the release event the Wayland server considered the key still as
pressed when going into the next application.
This change ensures that all events are also passed to the wayland
server. As no surface has focus we can be sure that it won't be passed
to the application, but it ensures that the events are processed
correctly.
Reviewed-By: bshah
Summary:
The interaction is changed to trigger the check for release from the
TabBoxInputFilter instead of reacting on modifier changes. That way
it's possible to check for the relevant modifiers getting released
instead of getting all modifiers in. Also this means that the checks
are only performed when relevant.
BUG: 368590
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2773
Summary:
When triggering global shortcuts we are more interested in the hold
keys than the currently active modifiers. E.g. capslock should not
be seen as "shift is hold". Similar we need to remove consumed
modifiers. Shift+5 is % and not Shift+% - the shift modifier is
consumed and needs to be removed from shortcut evaluation.
To support this we need to have the actual state directly from
xkbcommon. Thus a new method is added which exposes the modifiers
relevant for global shortcut matching. In addition on every key press
all consumed modifiers are calculated and kept so that they can be
used for shortcut matching.
In addition a workaround is added for Backtab. Similar workaround
exists in kglobalaccel for X11. The problem is that our shortcuts are
stored incorrectly: Shift+Tab instead of Backtab. Thus a mapping back
is required. To make everything worse KWin registers the wrong key
sequence "Alt+Shift+Backtab" which doesn't make any sense and is
broken on X11 at least.
The workaround supports both special cases. The one for Backtab should
be turned into Shift+Tab and also KWin's special case of adding shift
to backtab.
CCBUG: 368581
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2768
Summary:
In order to add more tabs which can further help monitoring how KWin
handles some aspects the DebugConsole is changed to not take keyboard
input. This means it can only be navigated using pointer device or touch
screen.
This is needed for adding a new tab to monitor clipboard changes. On
Wayland sometimes windows don't get the clipboard, so it would be
helpful to have a debug monitor to see when the clipboard changes. But
for that debug console window may not take keyboard events.
To support this DebugConsole sets the WA_ShowWithoutActivating attribute
which gets honored by the InternalWindowEventFilter and does not forward
key events to such windows.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2620
Summary:
The Effect class is extended by three new virtual methods:
* touchDown
* touchMotion
* touchUp
The methods return a boolean value so that the events can be filtered
out. E.g. an effect which has also a mouse grab installed wants to
filter out all events, other effects don't need the events exclusively.
This is a difference to how e.g. keyboard and pointer events are handled.
But is more close to how KWin's internal input event passing works and
makes it easier to get touch event: one does not explicitly has to grab
the events. It's also closer to Wayland where all input events are
available.
As a first example the Present Windows effect is adjusted and allows to
activate windows through the touch screen. As much code as possible is
shared with pointer input.
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2450
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:
Restores feature parity with X11. Global shortcuts need to trigger
also for repeat events. An example is the volume key or screen
brightness.
For other shortcuts like showing yakuake it does not make sense to
trigger on repeat. Thus a long term solution is to add a flag to
global shortcuts whether the key should trigger on repeat.
BUG: 366608
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2413
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
Summary:
Gesture events are swipe or pinch events on a touch pad.
This change implements basic support by:
* wrapping them in LibInput::Event
* processing them in LibInput::Connection and emitting
dedicated signals
* Forwarding them in InputRedirection to PointerInputRedirection
* Support them in the internal input event filter
* Printing debug information in DebugConsole
Further handling is not yet done. In future the following should be
implemented:
* activating e.g. zoom and present windows on pinch/swipe gesture
* forwarding non global gestures to KWayland
Note that forwarding to KWayland is not yet useful as QtWayland does
not yet have support for the unstable protocol. No Qt application could
make use of it yet. So for the moment just global gestures is the best
we can get.
Test Plan: Looked at output of DebugConsole when triggering gestures
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2359
Summary:
This is a workaround for QTBUG-54371 resulting in QtWayland never
requesting the input methods panel without having keyboard focus.
Thus also the virtual keyboard is not working.
With this change we go back to always announcing a keyboard and
binding the virtual keyboard to whether we don't have an alpha-numeric
keyboard instead of whether there is a keyboard on the seat.
Reviewers: #kwin, #plasma_on_wayland, bshah
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2343
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
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:
The signals emitted by LibInput::Connection carry the Device for which
the input event was received. This Device is passed to the input handlers.
Custom event classes are added which extend QMouseEvent, QKeyEvent and
QWheelEvent respectively and expose the Device. The Device is only passed
around as a forward declared pointer, so even if compiled without libinput
support, it should still compile.
Event handlers which need to get access to the Device can now just cast
the event pointer to the custom class and access it. This can be used in
future to handle device specific key codes, etc.
As we don't have a proper event classes for touch events the event
handlers do not yet have access to the Device. Here the internal API
needs to be adjusted in future.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1667
Summary:
Just because we have a power button, doesn't mean we have a keyboard.
So let's bind the seat keyboard to whether we have a proper keyboard.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1681
Summary:
Qt's touch event API is rather difficult and complex to implement.
As none of KWin's internal windows supports multi-touch gestures yet,
this is going the easy route and just simulates a left mouse button
press. If in future need arises for touch gesture support on KWin's
internal windows, this can be added.
Test Plan: Tested on exopc with DebugConsole and auto test
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1661
Summary:
Touch events are emulating mouse events, in particular left mouse
button.
With this change one can move windows through the decoration, use
the decoration buttons and also support the double click action.
As finding the decoration is pretty much exactly the same as for
pointer events, a new base class is introduces which provides the
functionality of updating the decoration and the shared common
variables.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1604
Summary:
Mouse actions like wheel and double click were restricted to the titleBar
area. This made the top most pixel non-interactive as it's not part of the
titleBarArea.
This change makes the complete titlebarPosition interactive. That is it
includes for a "normal" (top) setup also the TopLeft/Top/Right section.
Thus the top most pixel can be double clicked, mouse wheeled, etc.
For the Wayland case the test case is adjusted.
BUG: 362860
FIXED-IN: 5.7.0
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1596
Summary:
The configuration file kcminput, group Mouse is parsed to decide whether
pointer devices should be in left handed mode. The config is applied
whenever a new device is added.
In addition the Connection listens to KGlobalSettings for a mouse
settings changed signal which might be emitted by the mouse KCM.
When such a signal is emitted, all pointer devices are reconfigured.
This allows to change the mouse handed settings on Wayland.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1543
All the important information like whether we are on the active vt are
also provided by Logind. So instead of integrating with VirtualTerminal,
which integrates with Logind, we can just integrate with Logind directly.
On special request by sebas. It's not really dangerous as by default
the xkb layout doesn't have it enabled. So if a user actually enables
it, we can also support it.
And now I'm going to reconfigure my layout again to not hit it by chance.
Reviewed-By: sebas
We want TabBox to operate on key press, not on key release. So far
it only operated on release as the press was filtered out by the
global shortcuts filter. To prevent that the tab box filter is moved
before the global shortcuts filter.
Note: first usage of TabBox has current window selected instead of
next. This problem is also visible on X11.
The TabBox implements methods for those events and performs same
logic as on X11. Click outside of TabBox closes. If the event is on
the TabBox we don't filter the event out and let the internal filter
forward the event.
Drag'n'Drop on Wayland allows us to improve the drag'n'drop experience.
When entering a window during the drag'n'drop operation, KWin raises it.
BUG: 36065
FIXED-IN: 5.6.0 (Wayland only)
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.
So far updating the cursor image was not really defined. It was possible
to use the cursor image from the wayland seat or have a custom set cursor
image. But there are no rules in place to decide which one to use when.
With this change a dedicated CursorImage class is introduced which tracks
the cursor image changes on the seat, on the decoration, in the effects
and so on. In addition it tracks which is the current source for the
image, that is whether e.g. the cursor from the seat or from effects
override should be used. Whenever the cursor image changes a signal is
emitted, which is connected to the signal in AbstractBackend.
Based on that the backends can directly show the image. The existing
code in the backends to install a cursor shape or to install the cursor
from the server is completely dropped. For the backend it's irrelevant
from where the image comes from.
A new feature added is that the cursor image is marked as rendered. This
is then passed on to the frame rendered in the Surface and thus animated
cursors are finally working. Unfortunately animated cursors are broken in
Qt (see https://bugreports.qt.io/browse/QTBUG-48181 ).
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.
As a Wayland server KWin does not have to emit additional key repeat
events (unlike X11). The clients are responsible for handling this based
on the provided key repeat information.
Internally KWin needs key repeat, though. E.g. the effects need key
repeat (filtering in Present Windows), window moving by keyboard needs
repeat, etc. etc.
This change introduces the internal key repeat. For each key press a
QTimer is started which gets canceled again on the key release. If the
timer fires it invoked processKey with a new KeyboardKeyAutoRepeat state.
This is handled just like a KeyPress, but states are not updated and
the QKeyEvent has autorepeat set to true.
The event filters check for the autorepeat state and filter the event
out if they are not interested in it. E.g. the filters passing the event
to the Wayland client need to filter it out.
Currently auto-repeat is bound to using libinput. This needs to be
modified. The only backend sending repeated events is X11, thus for
other backends it should be enabled.
Whether creating a timer on each key event is a good idea is something to
evaluate in future.
Reviewed-By: Bhushan Shah
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.
So far the key handler in the InternalWindowEventFilter used the
PointerInputRedirection's internal window. This had the result that
key events were only delivered to an internal window if the window
was under the cursor.
This change tries sending the event to the latest created and visible
window. Thus e.g. with nested context menus it goes to the current
sub menu as expected. The return value of sendEvent is used to filter
out the event.
