Seat correctly emits dragEnded when a DataSourceInterface is destroyed,
and stops the drag.
However WlToXSource lives slightly longer to finish handling any other
visits. See the guarded delete statement in Dnd::endDrag.
With recent fixes use is mostly a hypothetical, but we still don't want
dangling pointers in our code.
XWL only clears up when a "visit" finishes.
If we end a WlToXDrag through clicking we call "WlToXDrag::end" but the
visit object stays alive, which obviously will never finish.
Both the visit and the drag object then effectively leak and are used on
the next drag.
Transfer emits "finished" mid way through it's own methods. If we delete
here transfer is left in the middle of methods like Transfer::timeout
with a dangling "this".
This allows running Xwayland apps as root. Xwayland started with an
empty Xauthority file. After kwin has received the display number, the
file is updated with an actual authority entry.
BUG: 432625
The selection owner must live as long as the X11 connection is valid;
otherwise Xwayland won't catch the corresponding selection ownership
change event, and the initialization sequence will be incomplete.
The major difference between this version and the previous is that kwin
no longer forwards the opacity to the app window if it runs as a
window window manager and a compositing manager. As Keith Packard said [1]
> The window manager support is only needed to forward the property from the
> application window to the frame; with the Composite extension, a
> compositing manager can then take that value into account when
> constructing the desktop image. Any X server can implement the Composite
> extension; the one in the X server project at freedesktop.org is just one
> such. It would be trivial to implement this extension in a direct FB
> based X server, or any other X server which places windows in off-screen
> images.
There are a couple of reasons to do so: (a) simplifies code, (b) we don't
temper with opacities on override-redirect windows.
[1] https://listman.redhat.com/archives/xdg-list/2003-December/msg00153.html
A recent patch made it possible to restart KWin when it crashes, this
opens the possibility to do it for development purposes. So far it could
be done using `killall -9 kwin_wayland`. This patch embraces this
functionality under --replace so it's a bit more documented and under
its own semantics.
It is done by returning the process with 133 exit code and picking that
code specifically as a wish to restart.
Some users reported performances issues after recent compositing
scheduling changes, in particular animations being laggy.
The issue is that sometimes it may take more than a vblank interval for
a buffer swap to complete. Previously, compositing was driven by a
timer and it wasn't synchronized to vblanks. If some frame is running
late, the compositor will just start painting a new frame, i.e. the
screen will be rendered triple buffered.
This change disables the swap events code path on Intel to restore the
previous behavior. Unfortunately, that may add an extra frame of latency.
The swap events code path can be enabled explicitly on Intel by setting
the KWIN_USE_INTEL_SWAP_EVENT environment variable to 1.
On Wayland, the highlight window effect is not guaranteed to work all
the time because it uses the opacity to determine if the animation has
completed.
This change rewrites the highlight window effect using AnimationEffect
API to make it work both on X11 and Wayland. The implementation is based
on how the translucency effect works.
It is reported that the self test produces false positives with some
drivers. At quick glance, there is nothing in particular extremely wrong
with the test. Since not a lot can be done about the test except making
changes in drivers, the severity of the log messages should be lowered
to avoid polluting logs.
Don't neglect the scale of the buffer for windows that we are rendering
on the spot.
Otherwise we will be offering a smaller size to what we are generally
using. More importantly, the ScreencastManager expects the buffers
scaled. This causes glitches when the stream starts otherwise as the
first frame triggers a resize.
CCBUG: 428594
Otherwise we'll be triggering a resize request first thing and never
hear back from the stream until a new frame is requested (which is often
rare when looking at a thumbnail).
BUG: 428594
ColorDevice gets recreated when outputs get removed and added back. This
means the output can be in an unknown state that does not match the
values in ColorDevice. So ensure we update after creating the device to
set it to a known proper state.
As it was pointed out in 6acf35e4cc, it is
better to return raw pointers than qpointers because returning a qpointer
is equivalent to constructing a new one.
