There are ways to do all these things but they are compositor agnostic - which frankly makes sense. I don’t want a random app running on my desktop querying these informations in a hacky way, while the whole of this information is stored nicely in memory by the compositor. They just simply have to provide an API for that - and that’s the beauty of wayland - they let the compositor implement any number of custom apis and the app can query which ones are supported by the compositor and vice versa.
> There are ways to do all these things but they are compositor agnostic
Maybe. But GNOME have found it difficult [0] [1], and the most basic of mouse control required a truly massive patch to KDE [2]. Everyone else just shrugs and says to use XWayland. Meaning there is no consistency on how to make basic accessibility work.
It isn't clear to me why reporting the mouse's location belongs in the compositor. You may not be rendering to a screen at all.
The end result being... Accessibility under Wayland is crap. Accessibility under X11 mostly works.
Sounds like the beauty of a lump of rock - any sculpture you can imagine could potentially "just simply" be carved from it.
To replace X11, then, we would need something more than Wayland: a design (as a spec or as a concrete component) for how all these parts that were left out are supposed to work.
Well, yes. Wayland is a display protocol and it does its work splendidly. X11 does a lot more than display management, and those things should not be put into the display manager yet again as it is a mistake.
Maybe there should have been a unified api for things people have been wanting to do for 30 years instead of people figuring them out 12 years into development.
