Basically everything would stop working with X, because X simply relies on being able to listen to everything. Actually there are nested xservers that do something like this, but now global hotkeys don’t work, it doesn’t have an api for screenshots, so those won’t work either and the like.
And you can probably add some X extension which can’t be queried properly, but then you can just as well create a new display protocol that actually knows about GPUs
I don't care if X sees everything (hell, even if X didn't, the kernel certainly still would). I only care that I can control which programs see which X11 events. Like, my hotkey program can see everything, but my Web browser can only see its own x-windows' events.
Re:Guide: Full Wayland Setup for Linux
by cycloptic on Wednesday March 10, 2021 @07:12PM
(#26418405)
There is some rough support for that in the X server, but it is lacking a good API or user interface, and the desktops that would implement that are doing it in Wayland.
Doesn't that strike you as odd? Like, why is it that X11 was so close to fixing the problem, but everyone who would benefit from it (and who touts Wayland's ability to do it) decides to just throw it all away and re-built everything from the ground up? I'd sure like to know what they know about this.
No, the hard part is building a good API and user interface that works for everybody. IMO that's mostly why there are a lot of half-finished and inconsistent things like that X11.
Doesn't that undermine Wayland's selling point of isolating clients' input? No one was clamoring for this until Wayland announced it, and no one was willing to put in the effort to fix it in X11 all these years (even though it would have been easier than ripping out X11 entirely).
That's one of the things Wayland was designed to do, of course implementations can build other things around it that allow privileged clients to break client isolation. The effort could have been put into X11 but it seems the people interested in this would rather put that effort into Wayland.
That's literally the essence of the CADT[1] model of software development. Why do a comparatively-small amount of unglamorous work to solve a bug when you can just burn everything down and rewrite it from scratch?
Not really, it's the same amount of work either way considering this doesn't exist yet.
Option 1: add an X extension that lets you configure which windows get to see which input events. Most clients don't actually need to see any events besides the ones they would see while in focus, so most clients don't notice.
Option 2: replace X with something entirely different -- different rendering, different input, different IPC, different organizing principles, different programming models -- and patch all downstream dependencies to use it.
If you can't see that Option 2 is clearly more work and more disruptive, I don't know what else to say to you.
The response I've heard to this question is entirely nonsensical: it could be done with an X extension, but getting adoption from various parties to make this work would be difficult. As if building an entirely new display system doesn't require orders of magnitude more work and buy-in.