- X
- Wayland + Gnome Shell
- Wayland + wlroots-based compositor
- Wayland + sway or any other non-wlroots based compositor
Is Wayland really that much better that this is worth it? Why can't Wayland be aware of the compositor like X?
Once the the need is understood well enough, a common extension will be written, and Mutter, KWin and sway/wlroots will implement it.
This is better for security than X11 free-for-all.
Like how they standardized nice simple things like taking a screenshot?
Full disclosure, I am a Wayland skeptic. I don't think your focus on X input security is as justified as you probably think.
I know in the Windows world, one of the UAC features was that a less privileged process can't send events to an elevated window.
In X11, I think last I checked most distros disable the XTEST extension by default out of security concerns. Skimming the warpd code, they are using XTEST for the X backend.
As I think of the keylogger problem, it's not really privilege escalation, is it? If you're running as the same user as all the other clients, you could ptrace(2) them and intercept their event loops. I guess there are some container-based app deployment solutions now where you could run stuff at different security levels, so maybe it's more of a legit issue now...
And most likely it won't be injection of mouse and cursor events, but something higher-level, like focus switching requests.
This one looks like a small feature in a compositor and not an external tool, really.
I guess it would take 100-200 LoC to implement in GNOME Mutter.
Excuse me for being blunt. I don't know if you understand how shitty of a design you advocate. Solid designs do not require modifying core components to write application level features the original authors did not envision.
Moving cursor around is a compositor's domain, not some arbitrary application's that decided to fiddle with the user's input.
An API should not be so preachy about which programs can theoretically be written. It should provide broad mechanisms.
It is very frustrating to work with people who think like you do, that 3 or 4 unrelated projects have to carve up narrow exceptions to how the platform works for every single use case, nominally because of theoretical harm of this exploit no one will write, but actually more based on your ego perception that you know better than every other developer on the planet.
So Wayland has this long list of impossible applications which are doable everywhere else. It's a prima donna.
https://github.com/rvaiya/warpd/tree/master/src/platform/way...
If there is a distinction, and there might be, "completely separate" is exaggerating.
Edit: I see that only wlroot based implementations are supported so far, and of those there are some things broken in wayfire. Perhaps this is what you're referring to?
I don't use it at the moment because of compatibility issues with some software that I use, but that's not Wayland's fault.
I mean, that's the whole biggest criticism of wayland, 15 years in and it still doesn't work (well?) with the biggest GPU brand. The criticism has always been about whether it is worth it to fragment linux land and throw away a few decades worth of work on X.
It's not just throwing away a decade's worth of work on X, it's making everyone redo that work per display manager (thankfully wlroots exists as a kind of Wayland shared library).