Wayland the "successor" LCA: The X-men speak

An X server has to support multiple monitors for X clients to be able to use them, too. Which wasn't the case for a very long time. Also, bear in mind that XRandR 1.2 is very recent - I think it landed in about 2007 or 2008? (And that massive massive chunks of how X works today, including multiple workspaces, etc, are not in any way part of the protocol, and require the compositor to participate in a number of _extremely_ complex protocols. But never mind that.)

> And you can't write a presentation tool that will automatically rotate monitor to portrait orientation and back, unless you make it part of the compositor.

We'd rather have the client tell the compositor about the orientation change, and let the compositor handle it in the most optimal way: either have the display rotated (which is only possible in a vanishingly small amount of hardware, and I do mean vanishing in the most literal way) by the hardware, or have the compositor do the rotation when it does the final blit. X usually emulates this with one extra blit from a shadow buffer, because it has no way to tell the compositor to do it. This has a very real power and performance cost.

Oh, and when your presentation tool crashes, one of your monitors isn't inexplicably left rotated. Also when anything else pops up on that monitor, it isn't inexplicably rotated because the monitor itself isn't actually rotated.

Ditto resolution changes: instead of having games change your resolution and then forget to change it back, with all your desktop icons moving around too, we have the games flag their window as fullscreen, and the compositor works out what to do - be it changing the mode or doing the scaling, or just centring the window if the client asks.

Again, instead of providing direct literal functionality equivalents, we've taken a step back, looked at the problem these interfaces were trying to solve, and tried to come up with a better way.

> "Client" definition in Wayland is different from X.Org. For X.Org all visible apps on the screen are X.Org clients. And most of them could never be Wayland clients. Under Wayland same apps have to be integrated with compositor.

Technically speaking, they (desktop, panels, screensavers) are actually Wayland clients; they're just using special private interfaces the compositor doesn't expose to arbitrary clients. They're not running in-process with the compositor.

> As long as there's no stable Weston API for dynamically loadable plugins, "weston plugin" won't be much different from "weston patch".

You might have more of a point if this actually changed frequently. The X server changes its driver API far more often than Weston does its shell API, and yet no-one complains (except driver authors).

Isn't the compositor a userspace tool? Can't it expose an interface for a command line tool if desired, maybe even have that interface standardized (such as via D-BUS). Doesn't the window manager/compositor have to participate at a fairly low level for R-and-R events anyway? I don't see this as something that's going to be a big change. The window manager/compositor already does mediate pretty much everything, with the existing X system being a giant wart on the side to be worked around.