Currently, a tiled window will be untiled when you start interactive
resize. But there are clients that start interactive resize as soon as
they receive a button press around their edges, e.g. Firefox, which
results in unexpected untiling. Another argument is that it makes
interactive resizing and interactive move consistent, they both would
untile the window after explicit user input.
BUG: 470687
There have been many reports that enabling HDR on NVidia can lead to KWin's atomic commits
being rejected on login, which means KWin can't display anything. To prevent users from
falling into that trap, this commit disables the colorspace capability unless the
KWIN_DRM_ALLOW_NVIDIA_COLORSPACE=1 environment variable is set.
This commit should be reverted once the driver problem causing the issue has been fixed.
CCBUG: 488941
The only reason for handling them is that the effect grabs the keyboard, which disables
global shortcuts on Xorg.
In the Wayland session though, global shortcuts still work while the effects are active,
and usually that works fine, as the global shortcuts filter filters out the key press events
before they reach the effect. Modifier-only shortcuts though trigger on release, so they
don't get filtered out and the shortcut effectively gets triggered twice, once by the effect
on press, and once by kglobalacceld on release.
BUG: 493589
Some hooks need to run on X11 startup.
On X11 this is handled by the login manager, for XWayland this is the
responsibility of the desktop.
Long term, we want Plasma to make XWayland actually on demand and therefore we
should use the initfd for these startup scripts before the application connects.
BUG: 493054
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.
Vlad Zahorodnii
Xaver Hugl
David Edmundson
Jin Liu
Nicolas Fella
l10n daemon script
Akseli Lahtinen