dmabuf buffers have the origin in the top left corner, so a texture with
attached dmabuf must have y inverted.
By correctly specifying the y inverted flag, we could leverage existing
infrastructure in kwin to handle vertically mirrored textures and make
simpler some projection matrix code in screencasting.
Even though the names seem to match, QtWayland maps button values
to enum values in ascendung order (as it does on X11). The wrong
mapping is usually not a problem because we send the native button
events to clients. However when the Qt names or values are used
for communication between KWin and a client this leads to
misunderstandings.
BUG:465463
FIXED-IN:5.27.1
This isn't necessary with atomic modesetting, as moving and setting are
the same thing. With legacy though, if the cursor was hidden, moving it
with the layer visible does not automatically show it again, so that needs
to be done explicitly
BUG: 461181
This has the benefit of providing a saner default for the values
of `opacityActive` and `opacityInactive` rule properties, both
in the UI and when reading the config.
The side effect is the same we have when changing default values:
if someone would have set a rule with some opacity to 0%, it will
be read as 100% next time kwin starts.
In this case it is a small price, as it is always easier to change
it back when the windows are visible that restoring it when they're
not, specially if it wasn't voluntary.
Once upon a time, in a moment of acute stupidity, I accidentally created a window rule making all windows completely transparent. I meant to go for 0% transparency when really the slider said 0% opacity. And once you've made the very window to change this setting invisible, the only way to fix that mistake is to log into a TTY or different DE and find the config file to edit manually. Since I've since seen several KRedditors fall into the same trap:
Show a warning when active or inactive opacity is set to ~~<= 15%~~ < 25%.
PointerInterface is a "Server-managed multicasting resource". As in we
have one QObject, managed by the server, but internally it represents
multiple resources from various clients.
We cannot control the lifespan of those resources, they may persist long
after we stop having these capabilities on the seat.
If we delete our pointer object when we stop advertising a pointer
capability we have race conditions with clients calling release, or
potentially even having a seat_get_pointer in flight.
It's easier and safer just to have PointerInterface last as long as the
Seat. If we don't have a mouse no-one should try to bind, and even if
they did or remained bound long after we stop having a mouse it won't do
any harm as there are no mouse events to broadcast.
QAbstractEventDispatcher blocks and waits constantly on every external event
processed; every timer or update from an X or wayland client, mouse
move or DRM event.
Right now every time this happens we go and check Xwayland for new
events, this is a system call (poll) that based on strace will
unsurprisingly immediately return with EAGAIN as there's nothing to read
from X. If there is something to read our socket notifier will fire. On block we do still need to read any events read in the meantime that weren't dispatched.
This cuts down our system calls significantly, which hopefully should have a
noticeable impact on performance especially when the kernel is under
load.
---
Found whilst analysing strace (by accident whilst looking for something else!)
In a simple case of xwayland nested running glxgears we go from 28 calls per frame to 21. With many many clients and more input events it'll be an even higher percentage.
The current state is inconsistent. Some window-specific signals are
exposed in the workspace, some not.
This change drops those signals. One should monitor the signals it's
interested in instead.
The blur effect is used to improve the contrast. The option was added
thinking "why not? it might be useful." This was perhaps a mistake and
it should have been added with a clear valid usecase in mind.
CCBUG: 457495
Leverage the standardized ShortcutSettings config object to handle
the shortcuts config for the tabox (setting default values, reading
and saving to KGlobalAccel, etc).
This way, we can remove the extra methods in TabBoxConfigForm and
improve separation between UI and logic.
It also fixes the actions getting stored untranslated when saving
from the KCM (until next restart of KWin)
Provide a new KConfigSkeleton (ShortcutSettings) so that the
KCModuleData knows if any of the shortcuts is non-default.
This improves the UX by showing an "orange dot" in system
settings when just a shorcut has been changed.
We also need to implement a new specific KConfigSkeletonItem
(`ShortcutItem`) that uses KGlobalAccel to retrieve and store
the shortcuts, instead of storing them in a config file.
This installs a socket notifier onto our xwayland socket, when a user
connects we launch xwayland. The client then connections once kwin has
established itself as the compositor.
For a full desktop plasma session this patch effectively does nothing
too useful as we still start kcminit and make xrdb calls on startup
which in turn will launch X, but for the same reason this patch should
be harmless now as we're still processing the xrdb calls before any
clients will connect.
By passing the config object to the TabBoxConfigurationForm, we
can handle it directly instead of bouncing information from and
back between the forms and the KCM main class.
Now the user changes in the UI translate to the config objects,
which can directly provide `isSaveNeeded()` and `isDefaults()` info.
This allows to simplify the logic on both classes, reducing the
coupling between them and minimizing the number of exposed public
methods and some boilerplate.
If the window has been originally on another output, make sure that the
window will be properly put back on it.
This logic seem to originate from 7d67380205,
but it's not necessary anymore because geometry restore will be updated
if the window is moved to another output by the user.
BUG: 465358
