there is no practical reason I can see for why this should be limited to
stderr only. we are not reading or otherwise consuming stdout, we should
just pass it on.
Context: If a display is removed, the corresponding TileManager is removed with it. This in turn removes every one of its Tiles with it, and when a Tile's destructor is called, it attempts to find a new replacement tile for any windows it was previously managing.
However, if the Tile is removed because its corresponding TileManager has been removed, this has the potential to cause a segfault in KWin, causing it to crash (I suspect a possible race condition? but not sure).
This MR correctly evacuates custom tiled windows & migrates quick tiled windows upon output removal.
BUG: 465522
Use input device specific apis to change the position of the cursor. The
main reason to do so is to break the assumption that Cursor position is
the same as pointer position, which I would like to rely on later to
merge tablet and pointer cursors.
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.
