Slashdot Mirror
Intel, Red Hat Working On Enabling Wayland Support In GNOME
sfcrazy writes "After shooting down Canonical's Mir, Intel and Red Hat teams have increased collaboration on the development of Wayland. Developers at Intel and Red Hat are working together to 'merge and stabilize the patches to enable Wayland support in GNOME,' as Christian Schaller writes on his blog. The teams are also looking into improving the stack further. Weston won't be used anymore, so GNOME Shell will become the Wayland compositor. It must be noted that Canonical earlier committed to supporting and embracing Wayland. Despite that promise, the company silently stopped contribution, and it was later learned that they were secretly working on their own display server, Mir. Intel's management recently rejected patches for Mir, leaving its maintainance to Canonical. Before Intel's rejection, GNOME and KDE also refused to adopt Mir. Intel's message is clear to Canonical: if you promise to contribute, then do so."
The code base is old and hard to work with from what I've heard from the X hackers. It has reached a point where it might make sense to start over.
To be fair, Wayland really was not coming fast enough. I follow the Wayland developer mailing list, and it is apparent Mir seems to have kicked the Wayland developers in the butt and gotten them back to work. And they did fix some mistakes, in particular they realized that the server has to do event handling so that input methods work, rather than the previous idea that clients would have to interpret raw device events. I think they also fixed the other complaint Mir had which was the method to allocate window image buffers could not work with Android drivers, though this area is very confusing and it is not clear if it was a problem and/or whether it is fixed now.
It's more like Canonical looking at the progress and direction of Wayland and saying, "we don't feel this product is going to be sufficient for our near term mobile goals and would rather roll our own to ensure product delivery"
Whether or not they were correct in this thinking is possibly open for debate. There's certainly been some things they've said publicly that were debunked, but that doesn't mean the core of their premise is wrong. They are moving to a mobile strategy that AFAIK just isn't a prime directive of Wayland, but I'm not well versed in all that is Wayland so maybe someone that is can clear that up.
The petty bickering is Wayland devs and fans getting butt hurt about some things Canonical has said publicly some of which has been proven wrong as I said above. Since then, it's been a cacophony of rants from the Wayland devs/fans with general Canonical/Ubuntu haters thrown in bashing on Canonical/Ubuntu/Mir/Unity at every opportunity.
I've just started tuning it out waiting to see how it all turns out. If there's room for more than one IDE, I don't see why there can't be room for more than one compositor. May the best product win where "win" is defined as the most market share.
Canonical bashing might be all the rage at the moment, but I can see how they are feeling a bit hard done by with all these accusations that they should have used subsequent products instead of the ones they wrote first.
My remote X11 clients run on these machines and present their UIs on my local X11 display server running on my laptop. While it is probably true that these clients are not transmitting XDrawLine and XFillArc protocol elements to render their UIs, they are still mostly assembling pre-rendered bitmaps, widgets, and font glyph assets to send down the wire for rendering on the local server. How is this going to work on Wayland?
Actually, what the clients are doing right now is assembling bitmaps, widgets, and font glyph assets into a pixmap on the client side, most likely without the benefits of GPU acceleration, and sending the result as an uncompressed pixmap over the wire to the X server, which hands it off to a compositor, which combines the pixmap with images from other applications and hands the result back to the X server. If they're luck enough not to need any special transformations or compositing effects, the clients may be able to leave the rendering of the individual font glyphs to the server, but that's about it.
With Wayland the clients are doing the same work to assemble the surfaces for their windows, but they get to use the local GPU to do it, and the result is compressed by a local off-screen Wayland proxy server using modern video codecs before being transmitted over the network for compositing.
On a desktop, the only advantage to Wayland is that it facilitates implementing a pretty compositing desktop. This is a fad that is already starting to fade from fashion.
Distracting toys like "wobbly windows" may be fading from fashion, but composited desktops are here to stay.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat