The primary purpose of the tablet input filter is to forward tablet
input to the clients. On the other hand, the purpose of the forward
input filter is to send input to the clients too.
In order to clean things up, this change merges the two.
This fixes client-side decorated windows such as chromium displaying
"black bars" when they are being interactively resized.
The idea behind the fix: send a sync request and block wl_surface commits
to freeze the surface, wait until the client repaints the window and acks
the sync request, unblock wl_surface commits (in response, Xwayland will
commit a new buffer), repeat the cycle if the pointer is moved again.
The issue was fixed upstream. Technically, it also introduces a new
behavior: super keys are interpreted as meta keys now by default. It
matches what qtwayland does and, in general, Qt controls handle super
keys very poorly. Wayland clients still receive native scan codes,
they are not affected by these changes.
This adds the orange highlights of which settings are changed within the
KCM.
The KCFG file is modified as QML bindings automatically convert
properties to lowerTitleCase, but then the settingName in the
SettingStateBinding is not and people spend ages debugging it. Writing
it explicitly makes it clearer. The config file format is unchanged.
BUG: 479019
It belongs in the TabletInputRedirection class, not in an event filter.
Because of that, the event filters are expected to pass the tool events
down the chain in order to update the cursor position, but there are
cases where we **must** intercept tool events.
Emulating tablet input via pointer input creates a few problems:
- the first one is that the same input event can be processed several
times. The first time as a tablet tool event, the second time as a
pointer event. Such a behavior can be unexpected and it did causes
issues in the past with the input in decorations, for example
- the second one is the overall impact on the code. It increases the
coupling between independent abstractions, such as tablet and
pointer input, and it makes the code far more difficult to adapt
to new design principles
- the third one is that it brings a new category of challenges related
to managing the wl_pointer state when the tablet tool interferes
with its state. This increases the potential for bugs where input
misbehaves or just plain crashes
On the other hand, all major clients and toolkits have already added
support for the zwp_tablet_v2 protocol. In addition to that, another
major wayland compositor, mutter, doesn't even attempt to simulate
tablet tool events, and mutter developers have confirmed that they have
not received much complaints about this.
Emulating tablet input was necessary when the tablet input protocol
was still young and most clients didn't provide support for it, but as
it has matured, I believe it's not needed anymore.
As the first step, this change disables tablet input emulation by
default. In order to enable tablet input emulation, the
KWIN_WAYLAND_EMULATE_TABLET=1 environment variable must be set. Note
that tablet input emulation can be buggy because of the changes that
went in to prepare the code for fixing tablet tool event filters.
Tablet input emulation is expected to be dropped a couple of releases
later, which hopefully, will provide enough of time for the clients
that still don't support tablet input to add support for it.
Currently, internal windows react to tablet input because of the tablet
emulation code, which creates its own issues. With this change, internal
windows will receive tablet input using native Qt abstractions.
The crtc in the drm pipeline may change between a pageflip being requested and the
pageflip event happening. If it does change, it could change to a nullptr, in which
case KWin would then crash.
This should fix https://crash-reports.kde.org/organizations/kde/issues/4603
When effects get deleted, they might call EffectsHandler::isColorPickerActive,
which checks the list of loaded effects. With the previous code, that would access
the already-deleted effects in the list, leading to crashes like
https://crash-reports.kde.org/organizations/kde/issues/37390/
To fix that, this commit moves things around so that effets lists are cleared first,
and effects are only deleted afterwards.
Adding Kirigami.Units.smallSpacing and Kirigami.Units.largeSpacing
to bottomMargin adds enough space to avoid items from overlapping
when there are a lot of windows open.
BUG:493253
FIXED-IN: 6.2.0
It may happen that the specified app id is a file path to a binary file.
In which case, the findDesktopFile() function will return that file path
and KConfig will try to parse a binary file.
On other hand, the findDesktopFile() function should ideally always
append the ".desktop" suffix. If there's no file with such a file name,
nothing should be returned. But due to some Qt applications providing app
ids with the ".desktop" suffix, the findDesktopFile() function also tries
to find a desktop file without appending the ".desktop" suffix. However,
the fallback code doesn't actually try to verify that the desktop file
name contains the ".desktop" suffix, which can result in the
findDesktopFile() function providing values that it shouldn't. In this
case, returning the file path to a binary executable.
BUG: 492584
Do not decide on the output when the window is empty, contains won't
report empty rects. We'll be sending leave events unnecessarily.
Make sure we don't pass unexisting outputs.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
The mouseclick plugin's official name is "Mouse Click Animation", but
the keyboard shortcut for toggling the effect is called "Toggle Mouse
Click Effect". Not only is this a bit inconsistent, it's also unclear
when set from the Shortcuts kcm; "Toggle Mouse Click Effect" could also
refer to toggling what clicking the mouse does (e.g. disabling it
completely or swapping left and right click).
This change makes the name of the shortcut "Toggle Mouse Click
Animation", increasing consistency and clarity.
BUG: 493275
FIXED-IN: 6.3
There's only two cases where a pipeline can be destroyed:
- hotunplug of a display, in which case DrmGpu already waits for all pipelines to be idle
- hotunplug of a GPU, in which case the pageflip events are safely ignored
In the latter case, it can happen that a pending pageflip event will never arrive, so it's
not just unnecessary but actively harmful to wait for the pageflip event.
Polling for drm events works for waiting on pageflip events, but if there's commits
scheduled for future submission, and that fails, no pageflip will ever arrive.
To fix that, this commit ensures at least one commit is actually submitted to the
kernel before polling for pageflip events.
BUG: 492167
Vlad Zahorodnii
Xaver Hugl
l10n daemon script
David Edmundson
Akseli Lahtinen
David Redondo
Aleix Pol Gonzalez
Christoph Wolk