Enlightenment Mysteriously Drops Wayland Support

jones_supa writes: According to Enlightenment 0.19.12's release notes, it's an important release that fixes over 40 issues, which is quite something, considering that previous versions had only a few improvements, with most of them being minor. However, the big news is that 0.19.12 drops support for the Wayland display server. Unfortunately, the Enlightenment developers have omitted to mention why they decided to remove any form of support for Wayland from this release, and if it will return in upcoming releases of the software.

Comments

I guess they realised...

[Viol8]

... that Wayland is a solution for a problem thats already been solved better.

Re:I guess they realised...

[jon3k]

It's just nobody's really asking for a replacement

No one asked Henry Ford to make cars, either. This attitude, specifically in technology, is baffling to me.

Re:I guess they realised...

[fisted]

init really was a bug ridden piece of garbage

Care to point out a couple of those bugs?

SystemD implements everything init did

And a lot more, yes

but does it right.

Hahaha, yeah, it probably looks right from a Windows-centric POV

Re:I guess they realised...

[Uecker]

It is a myth that supporting old drawing primitives in X11 somehow slows down modern clients and you can essentially have the same buffer handling as Wayland with X. In fact, the design of Wayland is basically copied from X minus some old parts which are not needed by modern clients. The problem with this is: Breaking compatibility with a decades old protocol for no good reason is just moronic.

Re: I guess they realised...

[Anonymous Coward]

Defense of merit is not hatred of women.

Re:I guess they realised...

[fisted]

What about the part where you were going to mention bugs in init?

Re:I guess they realised...

[ardor]

If one of the X developers essentially calls X obsolete crap, then I think we should listen to him.

There are certain things that just don't work well in X. One of them is vsync, which requires a rather large amount of nontrivial workarounds, like Intel did.

To get something like vsync integrated properly, you need to fundamentally change how frames are updated. This is what Wayland developers refer to when they say that "every frame is perfect". The X11 model is essentially dumb drawing and updating, with no regards to complete frames. It goes further when you have for example 2 videos on screen. Even if both have the same framerate, temporal jitter will cause lots of problems. With a display server like Wayland, it is possible to inform the server that "surface X needs to be presented at timestamp Y", giving the server the chance to correctly schedule and group together updates. This possibility doesn't exist in X.

X is an anachronism, designed for graphics hardware from a bygone era. X does not in any way reflect properly how today's graphics chipset work. Sure, X can be used, but you need to use so many extension that very little is left from core X, at which point you have the display server equivalent of the Ship of Theseus.

One other big problem with X: it is single-threaded. Applications *can* cause X to block and become unresponsive. LibreOffice is good at this.

That said, I am not particularly fond of Wayland. I think it is a step in the right direction, but I slightly prefer the DisplayPDF approach of OSX. I believe certain primitives like text do have to be part of the server. Not for network transparency, but because rendering text is not easy, and especially because it makes it easier to deal with display scalability issues (physical size, PPI etc.) and multi-monitor setups (and also allows for very nice benefits like system-wide font atlas caching). However, in order for this to work properly and efficiently, you need to merge the display server interfacing libraries (= the equivalent of libX11/libxcb), the server itself, and the UI toolkit(s) to work consistenly across the board (and this is what OSX Quartz does). In particular, this requires the protocol between the interfacing libraries and the server to be opaque, implementation-defined, and not guaranteed to remain the same. This is because it makes modernizations, subsystem replacements, and extensions much easier. In X, there are still old extensions around because some old programs use the (Xinput vs Xinput2 for example). With such an encapsulated protocol as I describe, there would be only one high-level input API. The possibility of API breaking changes would not be that high, since unlike in the 80's and 90's, these days, the essentials of a 2D on-screen user interface (basic widgets, interface structures, crucial features and behaviors etc.) are well-known and stable.

Re:Yes and?

[Anonymous Coward]

Those knowledgeable in the horrible language of C...

That's where I stopped taking the article you linked seriously.