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."
It's exactly what the Linux desktop needed! Thanks, everyone!
There's no -1 for "I don't get it."
KDE's support is also in the works but further down the line. I think later 2014 or early 2015? Can't find the schedule at the moment. Enlightenment 18 has partial wayland support with full support expected in 19.
FINALLY we're going to be free of X. Of course, I still suspect it will take some time to iron out the wrinkles to the point where the experiences on wayland for the various DE's are relatively bug free and are as smooth as butter.
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.
Canonical seem to be steadily trying to create a single 'us only' distro. Good that others are seeing through this.
Additionally, X11 does a lot of things that have been taken over by toolkits. GTK and Qt don't even use X11's drawing and font facilities anymore, they handle it themselves and then dump a buffer for Xorg to display.
There are certain things you cannot do with a pure X solution, much related to seamless transitions at login.
They argue that the seemed advantages of X, don't get used in the real world. In practice, rather then truly using network transparency, most of the time they just send bitmaps across the wire to update the screen. Because of this, by starting from scratch without this unused functionality they can make a faster, less resource-intensive, and prettier UI. For over-the-network usage they can just use a protocol to sent the updates, after they are rendered on the side with the application (clients and servers with X always feel backwards to me), which is what gets done in practice with X anyway.
Basically, if you aren't a developer, you wont care. It just gets more pretty. If you are, it gets easier to make things look better.
Care to supply actual evidence of these claims? Because anyone can make wild claims, what gets attention is evidence, which your post is lacking.
I've read the article on Wayland at Wikipedia, but I still don't know why they want to replace X.
'Cause writing new code is cool, while supporting and debugging old code is boring.
Basically, if you aren't a developer, you wont care.
I think you mean: if you don't use the features of X that many of us use X for (like being able to efficiently remote display over a LAN), you won't care.
Red Hat is open source. You can see for yourself if there are any backdoors. I don't think that you'll find any, though.
This video seems to provide a good explanation of the motivation for Wayland.
Shuttleworth is threatening Linux users' elite club by finally showing signs of actually making Linux work on the desktop and popularizing it. That's what pisses people.
Debugging and maintaining old code that no one is using is annoying and pointless. Particularly when you know you can do better, but are hamstrung by the X11 requirements.
no, no I dont.
Read what I said again.
In the real world, the network transparency support features are not used, EVEN WHEN YOU ARE USING A REMOTE DISPLAY because it's easier and more effective to actually render on the remote machine and bang the interface, so that's exactly what every widget toolkit does.
Why not? If no one uses it anymore, it's dead code that simply increases complexity. And once you start removing those dead bits, you can't call it X11 anymore. So you fix it to better fit the most common use cases and the easiest way to do that now is by rewriting it. Particularly when that code was written against a 30 year old standard that has been receiving workarounds to account for new hardware for years.
If the reason is that parts have been implemented in GTK+ and Qt then that sounds like a negative abstraction. There's lots of other toolkits which I'm sure users still would like to run. If all toolkits have to implement something then X is the proper place to put it.
Like or hate Ubuntu they recognize the consumer trend moving to low power SBCs. ARM is already dominating in this market and, according to wiki:
these parts [of mir] include Android’s input stack and Google’s Protocol Buffers. An implementation detail in memory management shared with Android is the use of server-allocated buffers which Canonical employee Christopher Halse Rogers claims to be a requirement for “the ARM world and Android graphics stack”.
So to me, it seems like the push towards Mir for Ubuntu is compatible with their vision of handheld, low power, devices completely replacing the desktop. This may well be the future of personal computing, and if I was Intel I'd want a seat at that table.
If it ain't broke, don't fix it.
Easier programming wise, maybe, but not easier on the network, or on admins'/users' sanity when using a remote connection. Transferring bitmaps around is bandwidth intensive and annoyingly slow, even on high speed connections.
Maybe they're not used, but they should be.
Why actually fix something when you can just add more duct tape and zip ties to what you already have...
All the code is open source. You are free to remove any NSA backdoors you find.
He failed at that when he launched 11.04 (or was it 11.10?)
At that point Linux on the desktop lost all the hope that it had.
My question is, why KEEP it at all? It's old, flawed, and has been patched up a lot of times to make it keep up. It has run it's course. What's wrong with retiring old things in favour of newer ones?
It should make for a much more responsive desktop. It doesn't stop running X apps either since X can run over Wayland. I expect there will be a transition of at least a year or two when most dists are running both by default until they've ported all the mainstream desktop apps over. Then it's likely that X will be something people have to install rather than a core package.
The API is strictly procedural and out of date, a new API can add the benefit of design pattern architecture (no, that doesn't mean it needs to be C++, this is an architectural point, not a language one). X is also full of serious security problems.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
There's the thing. X was written when there were no other toolkits, at least not of note (Motif?) so X does everything. As newer toolkits were added (GTK, etc) it made sense for them to do certain things, and many of those have become redundant in X. X is many layers of old code, a refresh is in order. Sometimes you have to stop saying "why fix it if it ain't broken" and just fix it. You don't really want to drive a model A while everyone else is driving a Tesla, do you? Besides, rather than create a successor to Ruby on Rails, which is a solution in search of a problem, IMO, why not create a successor to X, which is actually useful?
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
I use KDE. Period.
If KDE doesn't work with Mir, and Ubuntu forces Mir with the 13.10 update, then I won't be updating to 13.10 from 13.04.
I may well have to do a reinstall with LTS, from what I'm reading. And that would piss me off to no end.
I do not fail; I succeed at finding out what does not work.
...while supporting and debugging old code is boring.
So, according to that philosophy, we really should all be submitting our /. input on punched cards into batch jobs and reading your driblets of wisdom on paper tape becuase 640K should be enough for everyone, right?
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
If all toolkits have to implement something then X is the proper place to put it.
No, if all toolkits have to implement something then a shared library is the proper place to put it. For the most part, that's what's been happening. For example, both Qt and GTK+ need to render fonts, so they rely on FreeType.
The problem with putting drawing primitives and font rendering in the X server is that applications generally want to compose these operations together in ways the standard APIs don't support, which would imply either lots of round-trips and wasted effort or moving the application's drawing code into the X server (like DPS). When both the X server and the application are local, it's obviously both easier and more efficient to hand all of the rendering over to the application. The interesting part is that even if the application is remote, it can be more efficient to communicate a compressed form of the result over the network rather than all the drawing commands and raw data required to assemble the same image locally.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
"Care to supply actual evidence of these claims?..."
Oh, please. If I had actual physical evidence, I'd be in some NSA sub-basement right now.
you seem to be supplying plenty of evidence to suggest you are a paranoid schizophrenic. no, seriously, i think you need professional help.
Anons need not reply. Questions end with a question mark.
second-time-is-no-longer-clever.png
Il n'y a pas de Planet B.
As I pointed out is another post ( http://slashdot.org/comments.pl?sid=4183357&cid=44792345 [slashdot.org] ), Boston Consulting Group is a central component of the "1%" and their influence around the world.
Hehe, well you are 100% ahead of many conspiracy theorists, in that you have more than a vague idea of who 'they' are. So good job there.
"First they came for the slanderers and i said nothing."
My grailslaves have been transcribing my /. posts onto stone tablets and then carrying them upRiver to the server for the last 10,000 years. Why should I abandon a system that continues to work perfectly well for me?
Il n'y a pas de Planet B.
The X graphics stack has bad performance.
Compared to what. It's the fastest graphics system out there. Just look at the benchmarks. The X is slow mantra is restricted to greybeards who resent it hogging CPU cycles on their 10MHz Sun 3/60 and kiddies who believe that anything old is bad.
SJW n. One who posts facts.
MicroXwin (http://www.microxwin.com) is a completely new X windows implementation which is small, fast and compatible withe standard X. Here is a video of MicroXwin performance on Raspberry Pi: http://www.youtube.com/watch?v=zttcdPtJN8A Raspberry Pi is some what dated. Here is a video of MicroXwin on more recent SOC such as Allwinner A20: http://www.youtube.com/watch?v=T18FhSTQ08k
Easier programming wise, maybe, but not easier on the network, or on admins'/users' sanity when using a remote connection. Transferring bitmaps around is bandwidth intensive and annoyingly slow, even on high speed connections.
Maybe they're not used, but they should be.
If you want your programs' icons to be rendered with new-in-1988 stippled lines rather than Cairo and your text rendered with blew-my-mind-in-1992 bitmapped fonts rather than OpenType, then yes toolkits could use the original X11 drawing conventions. However not many people actually want that.In any case, if you are happy with every toolkit implementing everything twice, why not be happy with one of those implementations being Wayland and the other being traditional-style X11?
There's also the problem that X11 is far too 'chatty' a protocol. While network bandwidth available to a typical user has increased exponentially in the last twenty years, the latency has not reduced by nearly as much. This leaves a serious problem with all the excess round-trips that can't be fixed without making completely incompatible changes to the protocol.
In the real world, the network transparency support features are not used, EVEN WHEN YOU ARE USING A REMOTE DISPLAY because it's easier and more effective to actually render on the remote machine and bang the interface, so that's exactly what every widget toolkit does.
I have three headless Linux machines and the only display I have is on my laptop. 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?
I keep reading that this will be supported through some backward-compatible protocol, but has anybody actually worked out the details of how existing X11 clients will migrate to this new protocol? My fear is that these clients will stop working with future versions of Linux and their replacements will not support network transparency.
Wayland has a real use case for mobile devices, but why make the same mistake as Microsoft by gratuitously trying to unify mobile with desktop? 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.
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
So you have x11 clients running on those headless servers? Pitty as that's not how you're supposed to do it. You're supposed to run the x11 server on those servers and use a single client to access them. Better yet, toss the x11 service and simply push them out as javascript/web pages instead.
Mod me up/Mod me down: I wont frown as I've no crown
Nope. While I like the idea of a method that uses cgroups to group processes on the fly, the rest of it's overwrought. The way he ties tons of dependencies into basic system binaries is an issue. (udev comes to mind)
You mean these? http://en.wikipedia.org/wiki/List_of_widget_toolkits
- Michael T. Babcock (Yes, I blog)
Really? Because games ported to Linux through emulation often perform *better* than their Windows counterparts.
I haven't seen a single example of the X stack having a speed problem -- memory usage, yes, speed, no.
- Michael T. Babcock (Yes, I blog)
Android doesn't use X11 because it would be redundant and required too much memory -- do you recall how much RAM the first Android dev phone had? 32MB. Good luck running X in that. I happen to have an X server running on my Android tablet just fine fyi -- and no performance issues.
- Michael T. Babcock (Yes, I blog)
My Linux desktop worked just fine for years* before Shuttleworth and his Fishery-Pricey, one-size-fits-all, ow-thinking-about-stuff-is-too-hard desktop even showed up on my "What the hell is this crap?" list, thanks very much.
*(Not 10,000 years, admittedly, but a number of them.)
Il n'y a pas de Planet B.
Because that's what the applications use. When the applications work on Wayland it may be time to call for X11 to be thrown out but for the moment it's too early for such calls to be anything other than premature fanboy hyped up rants. ... some day".
I'd be far less critical of Wayland if they took the approach of "look what it can do!" instead of "X sux and Wayland will be able to do everything it does so much better
X ran just fine in under 32MB back in the day, though I haven't had such a machine in a while.
SJW n. One who posts facts.
Nice to know. :-)
How is this going to work on Wayland?
My understanding is the network transport is still under discussion. But Wayland could send bitmaps of each windows surface and you will have a thin client of some sort on the remote end that renders these surfaces on your screen, lets you move them around etc.. Your client will send things like mouse and keyboard events in the other direction, receive new bitmap fragments, resize events etc.
Of course since Wayland is running over OpenGL ES 2.0, it's possible to imagine more exotic scenarios where shaders, vbos, textures etc actually live client side and the server side OpenGL ES impl treats the client like a remote GPU. Or maybe some hybrid where client / server balance the load in some way doing some stuff on the server and some on the client. Could be gnarly but there is potential to offload at least some processing out onto a client assuming its capable of it.
I expect in the first instance that it would just be sending server side rendered surfaces since this is obviously far easier to implement.
On X, you can have a Gnome application running on KDE and vice versa, will this also be the case when the desktops will use Wayland?
Or do you have to use XWayland to ensure that this interoperability still works?
Doesn't X contain a lot of shared libraries? That was what I was thinking of.
You're supposed to run the x11 server on those servers and use a single client to access them.
WTF?
The X server runs on the desktop (client) machine. The X clients run on the server machines.
Watch this Heartland Institute video
Why do you need full network transparency (which you don't really have anyway in X)? I see no advantage to the network transparent features of X compared to a modern implementation of RDP, but I could be missing something?
If anything RDP would be more efficient than what X has now as X has effectively degenerated to VNC style transmitting of images over the network. As a user of many such systems I can say with some certainty that in terms of speed and usability X VNC RDP, and the performance gap between VNC and RDP over a slower network is quite profound.
Why are composited desktops important?
For every problem, there is at least one solution that is simple, neat, and wrong.
vi is a *beepity beep beep* text editor.
Emacs is my favorite operating system.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Why are composited desktops important?
Compositing is used to implement various helpful window management features which are not possible when drawing directly to the screen, like the "Exposé" / "Present Windows" effect and live previews during task switching. It also allows various accessibility improvements, like contrast-enhancing visual filters and smooth screen magnification, and is required for the efficient implementation of translucent windows, including merely non-rectangular windows with antialiased borders.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Doesn't X contain a lot of shared libraries?
Yes, but once the functionality is in a shared library, it's no more work to use the library from the toolkit than it would be for the toolkit to describe to X what it wants X to do with the library. On the contrary, by removing a layer of indirection it's easier for the toolkit to get the effect it wants, since it has the full API of the library to work with rather than just the portion exposed via an extension to the X11 protocol.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
How many applications use X11? How manty use GTK or QT?
Watch this Heartland Institute video
...has anybody actually worked out the details of how existing X11 clients will migrate to this new protocol?
I find Unity completely unusable and so I don't use it. I just installed mint 15 on a powerbook pro the other day, and as always, at login I have several desktop mangement options, including xfce (which I use), and Unity, as well as several others. I doubt seriously that X will be yanked from most distrobutions without a fallback. In fact I suspect you'll be able to use X for years to come if you so choose.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
VNC is a pixel-based screen-scraping desktop replicator. I have never seen one that performs better than individual X11 clients over a fast LAN, and over the Internet it's even worse. Besides that, I already have a full X11 desktop running on my local machine, so I don't want another desktop environment intruding. I just want the individual clients to display on my existing X11 server's desktop. This is especially important when working with several remote hosts.
RDP is a little better in that it has some understanding of the higher-level desktop objects it is rendering. But it still functions as a complete desktop that really wants to take over your entire local desktop.
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.
Yes, I think you are right for the most part, especially with Gnome and GTK applications. It explains why the resource tab of gnome-system-monitor consumes over 1MB/sec of bandwidth on my LAN. It's a shame really since it could have been coded to be much more network efficient if it would just draw the damn lines on the server side instead of rendering them into a pixmap on the client side.
In general Gnome is extremely network unfriendly. I get tons of error messages on the console because Gnome applications feel so insecure when they can't connect to a Gnome desktop. They seem to work fine, but it's annoying.
Composited UIs are important for mobile because of the limited physical screen space; it gives additional information beyond the spatial dimensions of the viewing surface. And the lower overhead and simplicity of infrastructure such as DirectFB and Wayland are also essential for mobile. On the desktop, not so much: with enough screen space I can be happy and productive with a tiling window manager and completely opaque windows. That and network transparency in my opinion trumps any advantage that Wayland would have in terms of desktop environments.
The GPU acceleration issue is puzzling. I've experienced this -- if there is no monitor attached to a Linux machine, then the GPU drivers are not loaded. There's no good reason for that (it's not an issue on Solaris), and I've read that it can be worked around with a dongle and a resistor attached to the display port to make the driver think there's a monitor there.
If Wayland will support legacy X11 desktop applications the way you describe, then fine, I guess I'll get used to it. But it seems like a lot of work for not much benefit: work that could be more effective if applied to the mobile use case.
X ran just fine in under 32MB back in the day, though I haven't had such a machine in a while.
So you believe between 1998 - when PCs with 32MB were common - and 2008 - when the first Android phone came out - there were no significant changes to X that could have impacted performance?
If you can't tell the difference why are you commenting here at all? The latter are toolkits that work with X or whatever is on the display layers below them.
Here's a little thing to show people if they are clueless fanboys or really understand the Wayland vs X thing: for Wayland to replace X for my workplace would require Wayland working on MS Windows. Confused? Then you have no idea why a lot of people use X and why we kick back against all the "X sux, let's throw it away for a framebuffer" stuff.
One good thing is several of the utter showstoppers that were supposed to remain in Wayland (eg. linux only by design) were changed so it is being developed into an option and the loudest most obnoxious clueless fanboys seem to have got bored and gone elesewhere.
RDP is a little better in that it has some understanding of the higher-level desktop objects it is rendering. But it still functions as a complete desktop that really wants to take over your entire local desktop.
That is a common misconception. RDP v6 released in 2006 added support for remote clients in an effort to compete with Citrix. RDP in windows essentially already does this except that by default the remote app that it launches is the explorer shell. Windows 2008 gave a good interface for doing that called RemoteApp.
But ignoring specific implementations I'm talking on a protocol level. The RDP protocol adds a whole world of features that simple network transparency doesn't such as pass through of hardware in a driverless fashion to the host system allowing instant access to files, printers, audio, USB ports, etc.
Also as an aside I switched from remote X11 to using xrdp due to speed reasons.
I dont care if its Mir (which I found to be superior) or wayland (which I believe will be the one with fast adoption and fully supported by the restricted drivers)... just give me the fastest solution and for god sake, fix the starting up "resolution change thing" that make impossible to display a fucking logo correctly...
Ahh, so nothing that's actually important.
For every problem, there is at least one solution that is simple, neat, and wrong.
Thanks for the info. I knew about RDP providing access to audio and printers but I didn't know that it supported seamless integration of remote apps into the local desktop. I'll have to check out xrdp.
No worries, but before I come across as a liar, it's the protocol that supports seemless integration. I haven't actually tried to see if xrdp implements that part of the standard as I use the full desktop myself, and the only time I've used remote applications was on a windows server.
It's not going to be as simple as recompiling the existing applications for a new qt or whatever. It's going to be a matter of rewriting the applications to support whatever changes have been made to behaviour in qt to work on Wayland for the bits it doesn't have out of X and the new bits that are not in X.
It also means a lot of hard work will have to go into qt or whatever to blit to the Wayland framebuffer instead of all the bits that X currently handles to do the same. E18 already has something along those lines with evas which is worth reading about (www.enlightenment.org) if your interest in the subject is real.
The more you understand about the subject the more your blind certainty will crumble. The Wayland developers are "confused" because they are trying different approaches to determine the best ones and didn't just choose one by gut feeling - there's nothing wrong with uncertainty when you are making something new. The first alpha version is not going to be a magic success.
I understand Wayland's purpose, but I also hope they do not ditch X11 too soon as it has been around for many many years and ensures maximum compatibility. Personally, X11 does enough for me and has good enough performance. Let's just not make the same mistake that Gnome did, by ditching the old ways too soon before figuring out the new ways first. If X11 continues to be developed, I will definitely continue to use it.