BlurInterface always used to be my go-to template when starting a new
protocol, we may as well make it up-to-date with the generation.
Code is reduced by a third.
Summary:
There is a race condition in the following situation:
- Server creates a global
- Client binds to that global (making a new resource for that global)
Simultaneously:
- The client uses this resource
- The server deletes the global
We then process an event for a resource linked to a deleted global.
This is noted in the specification, the client documentation says:
"The object remains valid and requests to the object will be
ignored until the client destroys it, to avoid races between the global
going away and a client sending a request to it. "
KWayland does not handle this at all.
The global's user data refer to our C++ wrapper
The resource's user data refer to *the same* C++ wrapper
When the global is deleted the resource user data now refers to garbage.
To fix the issue, instead of setting the resource userdata to the
global, we set it to a smartpointer to the global stored on the heap.
We can then validate if our global is still valid.
Theoretically this applies to every global
Practically there are only 3 globals that don't have the lifespan of the
server. Output (which is read only and doesn't matter), Blur and
BackgroundContrast.
Blur resets it's global when a screen geometry changes.
Unfotunately this exactly at the same time that Plasmashell is
doing a lot of processing and creating some blurs.
Test Plan: See unit test
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, anthonyfieroni, plasma-devel, #frameworks
Tags: #frameworks, #plasma
Differential Revision: https://phabricator.kde.org/D7870
Summary:
Destroying the BlurInterface on the server side before the client has a
chance to cleanup results in a protocol error:
wl_display@1: error 0: invalid object 7
Which would terminate the client. If we would not destroy the resource,
but only delete the BlurInterface it could result in heap-use-after-free.
So just don't do anything, the client needs to cleanup which will result
in the BlurInterface being deleted.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1708
Summary:
This change standardizes the behavior regarding the destructor request.
The destructor should destroy the resource and nothing else. The
Wayland library invokes the static unbind method once the resource is
destroyed. The implementation provided by Resource::Private::unbind
triggers a delete later on the Resource. So there is no need to trigger
a deleteLater from the destructor request callback.
This change adds a generic implementation to Resource::Private which is
now used by all inheriting classes replacing the custom implementations.
Test Plan:
For a few Resources the test is extended to ensure that the Resource
gets deleted on server side.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1679
Summary:
Not needed as the dtor of the Resource ensures that the wl_resource
gets destroyed.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D1680
Follows a useful change added in the kwaylandScanner tool the
s_version becomes part of the Private class.
Also fixes the related generation in the tool.
a protocol to activate the blur behind windows and to
optionally set a sub region of the window where to apply
the blur to, in case the window is shaped
REVIEW:125015
