The main motivation is to use the same timestamp units as kwin core
so ScreenEdgesFilter can provide timestamps as is without performing
extra conversions.
Motion and button events are different and need to carry different payloads.
Furthermore, the current design is inconsistent with how other events are
handled (except some tablet tool events that need similar treatment).
This is a precursor change to porting pointer events away from QEvent.
In https://invent.kde.org/plasma/kwin/-/merge_requests/6747
the comparison with window heap geometry was done with the
heap x/y/width/height properties to detect if the drop was done
off the heap, but this is wrong, because in Overview
window heaps are positioned with Translation transforms, so
we need to properly mapping its geometry with mapToItem
which is transforms aware
scripts could trigger some asserts:
* it was possible to tile unmanaged windows, which caused an assert on
!tile at window teardown, simply forbid it.
* if a window was tiled as soon it appeared, it was possible the window
got destroyed before commitTile was called, causing an assert in
commitTile !isDeleted, in this case only make sure the tile we are
assigning is null
If the screen is locked, but the lockscreen isn't ready for painting,
pickFocus() returns the active window. This somehow leads to the
meta key getting "stuck" if you lock the screen with Meta+L.
BUG: 495325
QInputEvent doesn't behave as we expected, if two input events are created
(it's pretty common when kwin needs to forward an event to a decoration,
etc), the last event can change the values in the first event even though
they are completely unrelated, which later breaks input processing in kwin.
See https://bugreports.qt.io/browse/QTBUG-121987
It just wrongly triggers modesets that will then (at least try to) ignore the
leased-away resources anyways, and regress performance on the other displays.
BUG: 495400
This new return value is mainly intended for usage trough scripting.
In scripting there was no safe way to know which were the two "new"
tiles after splitting, because two things can happen: either
two new child tiles are created or if the layout direction agrees
with the current layout, a new sibling is created, so we can't
rely on tile.tiles.
This makes it return an Array containing the result of the split,
making scripts much cleaner and with less heuristics.
This change introduces a check for the ID_INPUT_TOUCHPAD property to
reliably identify touchpad devices. By doing so, we ensure that the
logic specific to touchpads is applied only to the relevant devices,
improving the overall robustness and accuracy of input handling. this
enhancement addresses issues where non-touchpad input devices were
incorrectly processed as touchpads, leading to unintended behavior.
Signed-off-by: YaoBing Xiao <xiaoyaobing@uniontech.com>
If another window accepts the touch up, that can seriously mess up the touch state and
cause for example the overview effect to misbehave when we have 2 screens.
Before, it could break in the following scenario:
- drm backend emits aboutToTurnOff
- workspace creates the dpms filter
- workspace gets some event that triggers it to update outputs
- maybeDestroyDpmsFilter sees that the output is on and deletes the dpms filter
- the drm backend actually turns the screen off
In that case, the dpms input event filter is gone and the output off. Unless the dpms mode
gets changed again by some other process, the output would now stay off forever.
The wp-tablet-v2 protocol implementation no longer uses this property,
and, in general, InputDevice::name() is more preferred as it's more
widely supported.
Since the ensureTabletTool() function is called before forwarding the
event to the event filters, the ForwardInputFilter doesn't need to
create a TabletToolV2Interface object anymore.
Tablet implementation is very input device oriented. If the tablet
protocol implementation works with InputDevice, we could offload some
tablet matching logic to the wayland protocol implementation as well
as making TabletInterface <-> InputDevice lookup more robust in case
sys names are unavailable.
We need a way of disabling interactive window moving in Plasma Mobile
(see: https://invent.kde.org/plasma/plasma-mobile/-/issues/340).
This adds a property on the window that lets us toggle interactive
window moving from a config setting.
David Redondo
Vlad Zahorodnii
l10n daemon script
Xaver Hugl
Ismael Asensio
Andreas Cord-Landwehr
Marco Martin
Jin Liu
Adam Nydahl
YaoBing Xiao
David Edmundson
Joshua Goins
Devin Lin