It’s not as much of rewriting Xorg cleanly but also rethinking how we handle graphical sessions as a whole, accounting for how tech works and where it’s going.
It does lead to things like not being able to put your window at position (x,y) because what if you’re in VR and now your window position is some 3x3 matrix. But that’s a good thing, we’re thinking of those use cases instead of writing something that will need breaking changes later. Wayland likes to make no assumptions, so you can use it on phones or even do some rather exotic stuff. You could implement a Wayland compositor that outputs a video stream instead of on a real screen if you want to. You can make a true multi-user compositor with multiple mouse and keyboards that’s not horribly broken like it is on Xorg. You can make a distributed Wayland compositor that runs across multiple machines. You can make a compositor optimized for e-ink displays. It makes no assumptions that a computer always have a monitor, keyboard and mouse, or what kind.
We could just write something that works and that wouldn’t have any of the typical Wayland complaints. But it doesn’t solve things like VR, phones, tablets, TVs, etc, it would only re-solve Xorg and displaying windows and titlebars and panels.
That’s why we’re not writing a display server, but instead a series of protocols that anyone can implement and handle however the hell they want. We can have specialized compositors rather than one giant display server that needs to implement every possible use case. We’re still not quite at feature parity on the desktop yet, but that’s just not the sole end goal of Wayland in the first place.
It’s not as much of rewriting Xorg cleanly but also rethinking how we handle graphical sessions as a whole, accounting for how tech works and where it’s going.
It does lead to things like not being able to put your window at position (x,y) because what if you’re in VR and now your window position is some 3x3 matrix. But that’s a good thing, we’re thinking of those use cases instead of writing something that will need breaking changes later. Wayland likes to make no assumptions, so you can use it on phones or even do some rather exotic stuff. You could implement a Wayland compositor that outputs a video stream instead of on a real screen if you want to. You can make a true multi-user compositor with multiple mouse and keyboards that’s not horribly broken like it is on Xorg. You can make a distributed Wayland compositor that runs across multiple machines. You can make a compositor optimized for e-ink displays. It makes no assumptions that a computer always have a monitor, keyboard and mouse, or what kind.
We could just write something that works and that wouldn’t have any of the typical Wayland complaints. But it doesn’t solve things like VR, phones, tablets, TVs, etc, it would only re-solve Xorg and displaying windows and titlebars and panels.
That’s why we’re not writing a display server, but instead a series of protocols that anyone can implement and handle however the hell they want. We can have specialized compositors rather than one giant display server that needs to implement every possible use case. We’re still not quite at feature parity on the desktop yet, but that’s just not the sole end goal of Wayland in the first place.