If they're rendered in prePaintScreen, the time needed to render them is not
accounted for in compositing scheduling, which may make KWin miss vblank
CCBUG: 482861
CCBUG: 452119
CCBUG: 482034
Streams are deleted with QObject::deleteLater(), it's still possible to
process some events before the stream is actually destroyed, which can
cause problems.
I guess sys/types.h is implicitely included on glibc but that's definitely
not the case on Musl libc. The include is however necessary to define
dev_t introduced in 3c82d5a919
There are behavior differences between QFutureInterface and QPromise.
The QFutureWatcher::finished() signal will be emitted in both cases
when the promise reports results or it is canceled.
Both frameSize and clientSize are rounded to integral XNative units.
So their difference must also be rounded to integral XNative units.
Otherwise we get cycles of rounding that can cause growing window sizes.
BUG: 481460
Otherwise it's theoretically possible to create a new ClientConnection
object for the zombie wl_client when its resources are being destroyed.
For example
- process early wl_client destroy notification
- the ClientConnection objects gets removed from the client list in Display
- process wl_resource objects getting destroyed
- if some code calls display->getConnection(zombie_client), it's going to
reintroduce the client in the client list
- process late wl_client destroy notification, it's going to destroy the
original and the clone ClientConnection object
This change prevents reintoducing a clone client object, by keeping the
original for a bit longer until it's actually destroyed. In the future though,
it would be great to kill the client lists in Display and ClientConnection,
and just use `static_cast<ClientConnection *>(wl_client_get_user_data())`.
If the pointer is constrained, the screen edge may push the cursor back,
which will work not as expected. It's also undesired to trigger the screen
edge while the pointer is constrained by some surface, in general.
As Wayland doesn't have a warp event yet, before this commit, warps were
dealt with like normal absolute motion events. This trips up games though,
which don't deal with actual absolute motion events well. As a solution
to that, until an actual warp event is a thing, we send a motion event with
a position + a relative motion event with no motion
BUG: 458233
CCBUG: 482476
