The blur crash
The problem
Blur is managed by a global. Presence of the global indicates we support blur at a compositor level. It's important clients know this as plasma adjusts its own UI accordingly.
When we change various settings we delete and recreate effects. This in turn recreates the blur global static.
There is a race in globals. If someone tries to bind between us removing a global and the client being notified, the client has committed a protocol error and will be killed. This is a bug in wayland itself.
On change of look and feel packages (most notably) we have so many changes signalled at once we hit this situation quite often and all clients die. We then get bug reports.
Options
Option 1
We just make the global, lazy-load but static. If we could blur once, we can assume we can blur again after restarting effects. We don't support dynamically changing backends, and the qpainter backend isn't for production use anyway.
Cons:
- not technically correct
- breaks if someone disables the blur effect explicitly and manually
Pros:
- pragmatically fine. Especially if we hid the option to disable the effect.
Option 2
We make use of wl_global_remove. This announces the removal to clients without removing it from our internal mapping so any pending binds still safely fail.
This requires access to the wl_global, which we don't have in our generated output
2.0:
Patch QtWayland scanner, wait for Qt6.
Cons: Doesn't help anything
2.1:
Ship pre-generated scanner output that we mod to expose things.
2.2:
#define private public
Cons:
- horrible
Pros:
- easy
Option 3
Introduce a boolean property on the global
This event would be emitted when the compositor can support blurring or not. Then we just always have the global alive. Could be somewhat API compatible.
Pros:
- simple for us
Cons:
- means changing the pending protocol on wayland-protocols
Option 4
Hide the trigger. We don't need to recreate effects as often. With a good cleanup maybe it won't be seen.
Pros:
- would maybe look smoother
Cons:
- the bug is still there... Still plausible for clients to hit for the wl_output case