Clearing Up Wayland FUD, Misconceptions

An anonymous reader writes "In clearing up common misconceptions about Wayland (e.g. it breaking compatibility with the Linux desktop and it not supporting remote desktops like X), Eric Griffith (a Linux developer) and Daniel Stone (a veteran X.Org developer) have written The Wayland Situation in which they clearly explain the facts about the shortcomings of X, the corrections made by Wayland, and the advantages to this alternative to Canonical's in-development Mir."

Comments

Am I the only one?

[Anonymous Coward]

Who thought that "The Wayland Situation" was the title of a 70s sci-fi novel?

Re:Am I the only one?

[K. S. Kyosuke]

It sounds like a title for a TOS episode to me.

Re:Am I the only one?

[aix tom]

I somewhat was more reminded of "Wayland is where Emperor Palpatine's secret toy-box was. All kinds of nasty dark side things on Wayland."

Re:Am I the only one?

[cyberchondriac]

I was thinking more of the "Weyland-Yutani" corporation from the Alien movie franchise

Remoting

[Anonymous Coward]

Better remoting than with X11? Seriously? I'm in!

Just recall to support authentication (certificates, kerberos, and/or ssh piping), and root windowless operation, and you will get every admin that works in corporate environments at least to test Wayland. If it manages to fulfill the promise on better reactivity (== better usability), Wayland will catch like wildfire.

Re:Remoting

[Nerdfest]

I really appreciate what Cnonical has done for Linux. I think they've helped push it to a much wider audience than it would have had otherwise ... but I'd liek to know why the hell they can't play nice with others and use/contribute to Wayland, KDE, Gnome, etc? They've come up with their own desktop, which is not bad, but now they're creating Mir instead of Wayland, and are apparently creating a new package manager as well. We'dget much better products out sooner if everyone worked towards the same goals.

Re:Remoting

[Anonymous Coward]

Wayland does not do any remoting, at all. The article only says it "should", which translates into DOES NOT.

Re:Remoting

[unrtst]

I've been a supporter of X11 for some time, but only as a user. I know how to use it, and it's more or less the same as it was ages ago. That heritage will be difficult to break, especially the network transparency it has (which some claim it doesn't really have if you're using DRI2 etc, but you don't have to use those).

However, I've read enough of these rants from both camps to start looking at this differently.

Back when X.org started, I was surprised that it became the norm so quickly. It did so because it worked, could be dropped in, and had some improvements.

AFAICT, Wayland isn't done yet. As a user, we're judging too early. Right now, they really only need to be convincing toolkit, driver, and X developers to get that development on board.

Once Wayland is drop-in usable with all common apps, it won't matter to the user except for how it performs in their various tasks. Once it gets to the point that, for example, a Ubuntu user could "sudo apt-get install wayland-somethingorother && dpkg-reconfigure somethingorother" to try it out, then we'll see if it lives up to the hype.

There are plenty of things it's saying it'll do that sound good. The parts that worry me from my naive perspective will be answered when it's usable, such as:
* apps having to do all the rendering. What about apps that don't do this now? Are we really going to force them through X, or will there be some middleware they can use, etc?
* the mini x server solution... there was a problem noted due to the change in coordinate systems. How will that be solved? What other problems may we run into? etc.
* the network transparency question. They haven't completed this yet. They may not ever do it (might be 3rd party). There's already some other attempts at this that show something can be done with it, but it's just not finalized yet. We just have to wait and see.
* remoting apps, and how that will relate to interoperability. Sounds like I'll be able to pull an X app up on my local Wayland desktop and have it displayed using the built in mini x server (maybe). What about the reverse? How do you export a Wayland app to a client that is only running X.org?

Seems to me that those are all solvable. Will the solutions pan out? well.. seems like those are still a work in (early) progress.

It's far enough now that there's no point in asking, "why do this?" or "why not fix X?" etc.. they're doing it, period. I'm done reading these things now, cause it's just a matter of "will it succeed?" (and it won't unless all the stuff people have been bitching about are solved, so who cares for now?)

Re:Remoting

[spitzak]

* apps having to do all the rendering. What about apps that don't do this now? Are we really going to force them through X, or will there be some middleware they can use, etc?

Apps can use the Cairo library to render. That is what most of them are doing now anyway, since that is the only practical way to get antialiased lines and scalable images on X.

* the mini x server solution... there was a problem noted due to the change in coordinate systems. How will that be solved? What other problems may we run into? etc.

The problem was not really described correctly. The Wayland developers have this idea that applications should not know what their window positions are (I don't agree with this btw). X applications when they do the X api to figure out the window position are told it is at 0,0. On X an application wanting to make a popup menu not go off the screen, compared it's window position to the screen position, and thus knew where to place the menu (on Wayland the client says what position it wants the menu in (relative to it's window) and is told how it will be clipped, so the client can try another position). This means some errors with the popup of menus in X applications.

I was under the impression that they "fixed" this by allowing the X emulation to get at the secret information about where the window is. I complained on the mailing list that this means that X clients have a special privledge and they really should allow regular clients to get this secret info, but was ignored.

* the network transparency question. They haven't completed this yet. They may not ever do it (might be 3rd party). There's already some other attempts at this that show something can be done with it, but it's just not finalized yet. We just have to wait and see.
* remoting apps, and how that will relate to interoperability. Sounds like I'll be able to pull an X app up on my local Wayland desktop and have it displayed using the built in mini x server (maybe). What about the reverse? How do you export a Wayland app to a client that is only running X.org?

It looks like they are planning to use per-window RDP. This makes sense because the api and remote clients already exist, and you would run an X RDP client to display the Wayland windows.

Re:Remoting

[fast turtle]

It's called Firefox, IE, Opera, Chrome, Webkit for the remoting aspect. That's one of the reasons Wayland isn't investing effort into duplicating functionality that's in X11. It's no longer needed. Better options exist such as RDP or even god forbid "Cloud Apps" as were seeing alot more of.

What I'm hoping is that they reach the point that the 2d-3d performance allows me to handle any DX9+ game in Wine at max monitor speed (50-60 fps) as I'm using an LCD. I don't game much but I'd love to have the ability to do so easily and reliably under what ever OS I'm using.

Re:Remoting

[visualight]

Outside of the lkml the focus seems to be shifting to the "I have laptop/tablet and I'm at Starbucks" use case at the expense of people who actually have work with linux servers (that may belong to someone else and run somewhere else). Numerically we're in the minority now. (thanks Ubuntu)

For example: The RedHat ***Enterprise*** Linux installer assumes that my *server* is going to migrate from subnet to subnet and need it's network reconfigured automagically from time to time. How nice.

Re:Remoting

[Harik]

Drawing stippled lines in the server rather than via a toolkit = exactly like ripping out the command line.

Thank you for making your worthless comment and taking up my time.

Re:Remoting

[You're All Wrong]

Erm - I use linux on servers. I don't have X on those boxes. Any shift away from X to Wayland doesn't affect me at all. Anyone who has X on a server is already a victim of creeping bloat. (Unless they are specifically remote X login servers, in which case, that's fine.)

Re:The Manchurian Candidate

[Anonymous Coward]

Because it would require completely rearchitecting and breaking the protocol.

Re:The Manchurian Candidate

[Gaygirlie]

Why not fix X?

The simplest and most obvious answer: it's easier and faster to just not bother and start from scratch.

Re:show me hello world on my own pc or STFU

[Anonymous Coward]

First, SDL isn't an alternative display technology, it's a library which works on top of X (and Weston). Second, I am running KDE on Weston right now and it is working pretty well. It's not ready to replace X for most users yet, but it's stable and getting close to ready for mass consumption.

Re:show me hello world on my own pc or STFU

[Microlith]

but have you ever tried to actually install one of them on your own machine and get a hello world program working?

Yes, I did it on my Raspberry Pi using the implementation of Weston that they discussed.

this crap is, at best, alpha quality software. its just utter vapor ware.

Making your ignorance plain is quite helpful to others in knowing to avoid you.

i sound like a grumpy old man, but thats because i have been hearing about the "demise of X" since, oh, around 1997. [...] And here we are, still with X.

Yes, here we are, still with X. That doesn't make X good and it doesn't mean Wayland has made no progress. In fact the biggest driver of the Wayland transition is the wide availability of graphics accelerators that we didn't have back in 1997.

I won't really shed a tear when X is reduced to a library that sits on top of Wayland. I will enjoy improved performance and compositing that Wayland brings.

i dont even know what its' called.

SurfaceFlinger. Of course, no one has actually adopted it. It's just prevalent because of Android.

Re:show me hello world on my own pc or STFU

[elfprince13]

Just as an interesting addendum, Quartz is a PDF-based display system descended from Display Postscript, and I'm pretty sure OS X/iOS between them have far more installations than X.

Interesting arguments...

[Anonymous Coward]

Media Coherence. Whats Media Coherence? In its simplest terms... Your browser window? That's a window. Your flash player window on youtube? The flash player itself, displaying the video, is a sub-window. What keeps them in sync? Absolutely nothing. The events are handled separately and right now you just pray that they don't get processed too far apart. Which is why when you scroll on Youtube ,or other video sites with a video playing, sometimes everything tears and chunks.

I've actually noticed that, and wondered why it did it. I figured it was a browser bug or something to do with my particular setup. Interesting that it's a much deeper problem according to TFA.

Since it is, is there some workaround? Because it's anoying as fuck.

Re:Interesting arguments...

[Swarley]

As per the article, there IS a workaround. It's called Wayland.

Re:The Manchurian Candidate

[Gaygirlie]

I have never seen a good argument for this.

Read the article, then.

Re:The Manchurian Candidate

[Microlith]

Well he gave an answer in the article: if you move to "fix X", you end up making X12. And when you do that, all the stakeholders in X come out of the woodwork and insist on preserving all the legacy parts of the system that, frankly, don't belong.

The way things have unfolded, X11 will become a library on top of Wayland. And that's perfectly fine.

Re:show me hello world on my own pc or STFU

[peppepz]

Why, did the machines running X ever outnumber the Macs at any point in history? Also, Windows is not UNIX, and neither is Android, which isn't even a desktop OS, so why would their prosperity be a measure of the "death" of X as a windowing system for UNIX?

Re:The Manchurian Candidate

[mark-t]

Which is what they amount to by inventing an entirely new system anyways.... So the difference is...?

Sounds like it's still "all pixels"

[Ungrounded Lightning]

Each application does its own rendering? 31-bit pixel counter?

This sounds like it's all pixels, like X, rather than geometry, like NeWS or display postscript.

So if I have monitors with high resolution I still have to tell all the applications to change their size, individually, or use a microscope to read the text, right?

If I stretch a window (intending to scale it, rather than just see more of what it shows) it has to go back to the application for re-rendering, right?

And if I have adjacent monitors with different resolutions they won't match up. Heaven help me if I lay a window across the boundary between two, the T between 3, or the + between four. Right?

Or have I missed something?

Re:Sounds like it's still "all pixels"

[Microlith]

So if I have monitors with high resolution I still have to tell all the applications to change their size, individually, or use a microscope to read the text, right?

You're using a modern toolkit, one that scales depending on the DPI reported by the display server, right? Wayland is entirely correct to be aware of pixels, it's your toolkit that should provide and operate with geometry which it translates into a rendered output that is placed into the buffer that Wayland manages.

If I stretch a window (intending to scale it, rather than just see more of what it shows) it has to go back to the application for re-rendering, right?

If the toolkit is any good, the application won't be aware of it.

And if I have adjacent monitors with different resolutions they won't match up. Heaven help me if I lay a window across the boundary between two, the T between 3, or the + between four. Right?

A bit of reading would suggest that scaling would be employed on a per-monitor basis, I don't have time to read in depth to figure out what the logic is behind it.

Re:Sounds like it's still "all pixels"

[Anonymous Coward]

I'm guessing there will be toolkit libraries like GTK and QT that will handle all that you mentioned, like scaling. Wayland will handle things at the pixel level, and hopefully do it well, and by leaving the higher stuff to the toolkits, wayland won't get overly complicated. (sorry for the runon)

Re:Sounds like it's still "all pixels"

[Anonymous Coward]

> You're using a modern toolkit, one that scales depending on the DPI reported by the display server, right?

I was under the impression that a "toolkit" is basically a software library that sits between the application and the X server, and that the application is tightly tied to the toolkit used for its development.

How, then, could an end user choose which toolkit he/she is using, as you suggest? Assuming the situation that Ungrounded Lightning described.

Re:Sounds like it's still "all pixels"

[Microlith]

How, then, could an end user choose which toolkit he/she is using, as you suggest?

Sorry, I phrased that from a developer's perspective. Few developers really have any need to worry about pixels in their UI, and shouldn't be for this very reason.

Assuming the situation that Ungrounded Lightning described.

Well if it's an arbitrary, raster-based toolkit then I assume it'll be scaled by some system default, just like they're scaled on OS X. It's a transitional period where we're going to be breaking things for a bit as we identify all the things that don't handle high dpi screens well.

Re:Sounds like it's still "all pixels"

[Kjella]

Not much, except that all modern Linux software already does this because X is utterly obsolete as a drawing toolkit. Wayland is pretty much the answer to "If we assume the toolkits look at X like a dumb framebuffer, how much of X can we throw away? And fix some deep design issues in a process." That's it, nothing more. It's not an either-or, nothing prevents you from building an overlay that talks geometry to clients and pixels to Wayland, if you can get any traction for that. But then you're probably going to compete with similar functionality in GTK+, Qt, wxWidgets, OpenGL, OpenGL ES, SDL and so on that all like to render pixels. Unless you can force developers to use one library like Windows and OS X can you'll be just another library clamoring for support. But they all need something to render on and that's Wayland.

Re:Sounds like it's still "all pixels"

[Darinbob]

Basically in the past we had a big fat X11 with big fat clients. Now it will be a thin display server with big fat clients. Much of the bulk in X11 was not being used or being done separately in the client anyway. Ie, clients are already doing all the pixels themselves rather than doing geometry if they're built on top of modern toolkits.

However what's not being talked about is what sort of layer is going to sit between Wayland and the clients. It won't be big and bulky though, it'll probably be thin. When they say "clients" they mean the client is going to be using a library that talks to some of this middle layer. Ie, the desktop manager, an entity that knows about all the screens you have, etc. However I'm pretty sure that early on that most clients will just be legacy clients using an X11 wrapper. Over time though there will be newer clients and new client libraries, the same way that toolkits started sprouting up after X10/X11.

Re:Sounds like it's still "all pixels"

[JDG1980]

I have been witnessing the failure of vector-based toolkits. Even as this brave new world rolls on, it has forgotten something, and that is vector-based toolkits produce abysmally bad font rendering on low-DPI monitors.

That's one way of putting it. Another way to describe the same issue: rendering decent text on low-DPI monitors requires a bunch of atrocious hacks (hinting, subpixel antialiasing, etc.). Therefore, low-DPI monitors suck, and we should work to get rid of them as soon as possible.

My light sensitivities are way not-normal, and anti-aliasing just looks wrong to me on anything less than a retina display. Ugly and usable is so much better than messing with my eyes.

In the next couple of years, the price of "retina" (>200 PPI) displays will go down. Before long it will make more sense for you to get a retina-type display than to subject programmers to the atrocious BS currently needed for scalable UI design.

Re:Sounds like it's still "all pixels"

[aliquis]

So if I have monitors with high resolution I still have to tell all the applications to change their size, individually, or use a microscope to read the text, right?

Something at least. And what's the problem with that? Don't you think whatever is drawing on the screen got a better idea about how things could be scaled anyway? What's the benefit of the alternative? I don't see any purpose at all, I assume you could possibly still describe pixels and hence not be unable to do what you want to do but of course Qt or whatever could draw curves and the window manager tell the applications which font sizes would be suitable for instance?

If I stretch a window (intending to scale it, rather than just see more of what it shows) it has to go back to the application for re-rendering, right?

I guess yes but wouldn't it have to be re-rendered regardless of where the scaling happens?

Guess the monitors with different resolutions and the same window being split on both / many would be a real problem but on the other hand I wouldn't place a window there I'd most likely want to have full screen windows on each monitor.

No mention of remote anything in the article

[LaughingRadish]

Not supporting remoting is a misconception about Wayland? I certainly didn't see any discussion about that in the article. Would someone please point out a web page that discusses Wayland's remote capabilities?

Re:No mention of remote anything in the article

[gigne]

there is more than one page

Re:No mention of remote anything in the article

[LaughingRadish]

Okay, I see now. Some other observations: 1) It sounds like Wayland doesn't do remoting yet. 2) The way they're talking about it suggests it's desktop-only -- no starting an application on some other machine and displaying it on the local machine.

#1 isn't too bad -- they're working on it. #2 has me more concerned. Are they planning on having it be able to export individual applications rather than just the entire deskstop?

Re:No mention of remote anything in the article

[Anonymous Coward]

FTFA, page 3, point VI:

every X app just gets its own mini X-server to deal with

That sounds like it will be pretty straightforward to support individual apps remotely.

Re:No mention of remote anything in the article

[Anonymous Coward]

each app gets it's own framebuffer. I send the frames for just that one apps buffer over the network.

In practice, most X11 apps basicly do this (poorly) already anyway. (or atleast that's the argument of the wayland developers)

Re:No mention of remote anything in the article

[LaughingRadish]

That's for X apps. I'm talking about Wayland apps. Can native Wayland apps be remoted? I don't want to have a situation where I'm given a native Wayland app to control something and that something is on a remote machine. I don't want to have a situation of "Well, it's native Wayland. You have to be on the system's console to see that." Further, I don't want to have to fire up an entire desktop session to watch a window that takes up a tiny fraction of the screen.

Re:No mention of remote anything in the article

[JesseMcDonald]

Remoting of individual native Wayland applications has already been demonstrated. The protocol is similar to VNC, capturing changes in the per-window rendering surface, compressing them, and sending them over the network. "Similar to VNC" does not mean remoting a whole desktop; a VNC-like protocol is merely used to transfer the contents of the window, in the absence of shared memory.

Modern X11 toolkits do more or less the same thing, but without the change tracking and compression. Having been designed to take advantage of fast, local, shared memory, they render each frame into a buffer (probably without GPU acceleration, since DRI isn't available) and send it in full, uncompressed, across the network. Remote wayland clients should offer significantly better performance.

Re:No mention of remote anything in the article

[caseih]

And they should know since many of them worked on these very features in X11.

Re:No mention of remote anything in the article

[visualight]

They address it by redefining in their own terms what network transparency means. That way they can deflect the issue with statements like this:
"X is Network Transparent.â Wrong. Its not.

###Network Transparency means that I can ssh -Y into *ANY* system and run *EVERY* gui application over the network without *ever* needing to install additional software.

Wayland developers and supporters consistently try to re-frame the discussion to imply that there is no issue and "we" are misinformed. It's like they're politicians behind a podium. Liars.

Re:The Manchurian Candidate

[jedidiah]

> The way things have unfolded, X11 will become a library on top of Wayland. And that's perfectly fine.

Sounds like X running on Windows.

If you don't understand what's wrong with that, or you try to claim there is nothing wrong with that, then you really have no clue why people are resisting Wayland.

Re:show me hello world on my own pc or STFU

[jedidiah]

> There are far more Windows boxes too.

Ironically, you Wayland fanboys are going to make sure that the remote access features that have been adopted by Windows are ripped out of Linux.

Re:The Manchurian Candidate

[fahrbot-bot]

Why not fix X?

The simplest and most obvious answer: it's easier and faster to just not bother and start from scratch.

In addition, X was originally written when networks and client systems were slow(er). Many of original design decisions are no longer appropriate with respect to the X server code complexity and maintenance requirements. A long (long) time ago, I wrote a program (called CXC - Concurrent X Control) to manage the low-level X protocol (think everything in the X11 Volume 0 book) and support transparent X traffic interception, blocking, redirection and insertion for a CBT application (called CAST) and, if I remember correctly, I remember wanting to off myself (or at least start drinking heavily) after trying to make sense of it all. Just my $.02.

Re:The Manchurian Candidate

[DrXym]

Fix the protocol (e.g. by using UDP and unidirectional traffic where possible, deprecating a bunch of obsolete crap) and you break it. It's no longer X any more. At that point why bother fixing X?

Re:The Manchurian Candidate

[JDG1980]

Why not fix X?

The article answers that question on the very first page. (Scroll down to the bottom.)

Re:The Manchurian Candidate

[DrXym]

No, it's rootless X running on Wayland which in turn is running on Linux. X is not going to behave appreciably different than if you were running it directly.

Re:show me hello world on my own pc or STFU

[JDG1980]

That's 20 years since linux was created. 20 years and the only widely adoptd alternative to X is on Android, and i dont even know what its' called.

Hold on there, cowboy – you can't just hand-wave away Android, since Android deployments outnumber desktop X11 deployments by several orders of magnitude! Android is succeeding at end-user adoption where X11 has failed miserably for your "20 years", so you should be looking at Android for guidance, not dismissing it as a blip.

By the way, when Linux is used in an embedded system like a media player, they usually use DirectFB or something similar (if they're not using Android) – not X11. The truth is that X11 is utterly, completely unsuitable for anything a non-technical end user ever sees.

Re:show me hello world on my own pc or STFU

[Microlith]

Android is succeeding at end-user adoption where X11 has failed miserably for your "20 years", so you should be looking at Android for guidance, not dismissing it as a blip.

The only lesson to be learned here is that if you've got Google driving you, you're probably going to succeed. Suggesting that there is anything to be learned here about X11 vs. SurfaceFlinger is ridiculous.

The truth is that X11 is utterly, completely unsuitable for anything a non-technical end user ever sees.

Which is entirely untrue. By that logic my N9 is completely unsuitable for use by anyone "non-technical" because it uses Xorg, but most people would be completely unable to tell.

Re:The Manchurian Candidate

[Microlith]

If you don't understand what's wrong with that

I've seen what happens when you run X11 apps on windows. All the fancy widget themes and whatnot break. If that's not it, then I invite you to enlighten me.

you try to claim there is nothing wrong with that

I love the blind implication that the exact same whatever will happen with Wayland and, therefore, we should oppose Wayland.

you really have no clue why people are resisting Wayland.

The only argument I've seen is the lack of network transparency, often poorly worded with no actual technical argument behind it.

Re:show me hello world on my own pc or STFU

[jon3k]

its just utter vapor ware.

http://www.youtube.com/watch?v=mQ97cK4Jp8I

Not a good architecture for alternate guis

[Anonymous Coward]

With the release of hardware drivers for the Raspberry Pi I decided to investigate Wayland a bit further.

One thing that has confused me about Wayland is "where are all the alternate GUIs?", X window managers number in the hundreds with every man and his dog writing one.. The extremely basic GUI seen in Weston has barely changed in years.

It seems that Wayland has thrown away X's 'mechanism, not policy' mantra, and the architecture combines device drivers, the display server and the window manager into one blob (the reference one being Weston). This means that every alternate GUI needs to know how to talk to hardware, instead of just how to lay out windows and control them, it's rather laughable. At least turn the hardware support and abstracted device driving into some sort of library,. Also there's practically no documentation on Weston to use as a basis for another GUI, and the code is barely commented.

Wayland may be good, but it needs many more years of work at the current rate and still has some big issues;

1) The terrible architecture that I mention above that makes it difficult for people to build GUIs.
2) Driver support needed for running, that doesn't seem to be forthcoming from some of the biggest names in graphics cards.
3) The fact that we'll need to run X clients in Wayland for years, if not indefinately. Negating most of the arguments of "but we can throw away the crusty bits of X, hurrah".

I'm not going to discuss the X remote support issue, I think that one has been done to death :)

Re:Not a good architecture for alternate guis

[loufoque]

Wayland and Weston are separate programs.
Weston is currently the only window manager for Wayland.

Re:Not a good architecture for alternate guis

[ArsonSmith]

It really does seem like a baby+bath water out the window type thing. the X12 link at the bottom of the article actually was much more interesting to me and seemed like a much more sane architecture roadmap.

Re:Not a good architecture for alternate guis

[ensignyu]

As far as drivers, the abstraction layer is supposedly EGL / OpenGL ES. Of course, that assumes every OpenGL ES implementation works flawlessly out of the box without hacking around bugs, etc, which is rarely the case.

AFAIK, Weston only supports Mesa right now. Nvidia doesn't provide an OpenGL ES library or Mesa support in their binary drivers, so you'd be stuck with the open source nouveau driver if you want to use Weston.

There's also the concept of nesting compositors, where the desktop window manager (kwin, gnome-shell, etc) would run as a session compositor and handle window decorations, drag events, and compositing, and then it would send the full screen image to the system compositor which would just do a dumb blit to the screen.

I'm curious about of the performance of this, since it sounds like you basically have:

1) App renders widgets/video/3D using OpenGL to a window pixmap, and sends the pixmap to session compositor.
2) Session compositor uploads window pixmaps to OpenGL textures and then renders the scene to a full-screen pixmap, and sends it to the system compositor.
3) System compositor sends full-screen pixmap to the OpenGL drivers, which displays it.

which seems like it'd use a fair amount of bandwidth shuffling back and forth pixmaps that might be nearly 2650x1600 for a maximized window, at 60fps. There might be some optimizations to pass off the images without compositing, e.g. for a full screen window or if there's no overlap, but there might also be some degenerate cases.

Re:show me hello world on my own pc or STFU

[Microlith]

Ironically, you Wayland fanboys are going to make sure that the remote access features that have been adopted by Windows are ripped out of Linux.

I see we're whipping out the baseless attacks now!

Re: The Manchurian Candidate

[slacka]

And, maybe if you had either
A) RTFA or
B) watched http://www.youtube.com/watch?v=RIctzAQOe44&autoplay=1
You could have added something Intelligent to this conversation.

Re:The Manchurian Candidate

[Sique]

As they say in TFA: Calling it X12 or X20 or whatever will call in all the persons who care about X trying to meddle. Calling it Wayland will leave the others mainly uninterested, so the developer team can work on stuff.

Re:Mir?

[coliverhb]

I went digging after reading this article, here's the only thing I've found:

Mir in Kubuntu

Halfway down, he compares the two - it doesn't look like there's much concrete info about Mir though.

Summary: Philosophical differences in development style, server-allocated buffers vs. client-allocated buffers.

Re:The Manchurian Candidate

[Anrego]

I've never delved too deeply into X, but none of the issues pointed out in the article really seemed all that compelling.

They seemed like the kind of quirks you end up in any large system. I assume wayland will trade them for a completely different set of quirks.

Re:show me hello world on my own pc or STFU

[Beardydog]

As the only other human I've seen mention Wayland on the Raspberry Pi, I'm forced to funnel my questions to you. I apologize. I tried to install it months ago using the huge pile of instructions at freedesktop.org. It didn't work. When they put the actual install package up, I ran that, and it sort-of worked. I have to run export somethingorother_path=/tmp/ && weston to run it every time. That's all fine.

I don't NEED it, but I'm excited to try it. And now here I am without a file manager, or really anything at all that runs under Weston. They all complain about needing an X display. Do I really have to install X11-under-Weston using their other huge page of instructions to do anything interesting? Because if I do, I'm guessing it won't work... Is there a repo, or are they any package around that I can install just to have some fun, and take it for a legitimate non-X11 spin?

I barely got Apache installed properly. I wish the Raspberry Pi Foundation would just release a Weston Testng Fun Times Image I could flash.

Re:The Manchurian Candidate

[maxwell demon]

In addition, X was originally written when networks and client systems were slow(er).

So if Wayland only works on a fast network, it will not win me. Heck, many X11 applications are far too slow over DSL (I guess those are the applications which do not use the X core, but all those "better" alternatives). I prefer a less pretty window I can interact with to a pretty one which I is too slow to use.

Re:show me hello world on my own pc or STFU

[Beardydog]

Also, I feel the need to watch Burn Notice every time I start Weston up.

Re:show me hello world on my own pc or STFU

[gagol]

I think you fall under the "Go ahead and implement X12 by yourself" category.

Re:show me hello world on my own pc or STFU

[Microlith]

I tried to install it months ago using the huge pile of instructions at freedesktop.org. It didn't work.

Given that the "huge pile of instructions" are build instructions, unless you're familiar with building from source it's probably best avoided.

I have to run export somethingorother_path=/tmp/ && weston to run it every time.

Probably LD_LOAD_PATH, because their setup is installing to the user's home directory and not the system, to keep things clean. It's entirely testing centric at this point.

Do I really have to install X11-under-Weston using their other huge page of instructions to do anything interesting?

If everything "interesting" you're doing currently uses X11 libraries, yes.

I barely got Apache installed properly.

No offense, but if this is true then I doubt you really need to worry about (or comment on the difficulty of setting up) Weston just yet.

I wish the Raspberry Pi Foundation would just release a Weston Testng Fun Times Image I could flash.

Which is wholly off topic for them.

Re:The only good thing about Wayland

[gagol]

Wayland is being made because the guy who writes it want too, not because there is anything inherently wrong with X.

Most Wayland developers are X developers, they did it exactly because X is a pile of bull crap...

Re:Mir?

[AdamWill]

There isn't anything about Mir. I think Phoronix made a booboo in their summary. It was only intended to explain some things about Wayland, Mir is out of scope.

Re:The Manchurian Candidate

[Darinbob]

Yes, because if it's not X12 then you can actually break it. If it's X12 then you'll be forced to keep some broken stuff. Maybe you'll be allowed to say that something is deprecated until X13 though, but that means it could be another 26 years until it's removed.

Re:The Manchurian Candidate

[Sique]

It was invented here. A large share of the Wayland developers are ex-X11-developers. They know X11 from the inside.

Re:The Manchurian Candidate

[Darinbob]

X was also designed when your workstations were very expensive, so having things like an X Server dumb terminal was a good idea. Keep all the jobs running on your departmental super mini computer, and hand out xterms to the staff. Save money and you get a larger display than you would otherwise (meanwhile PCs are still running DOS).

What's interesting is that in the intervening decades that all the power moved over to the client on the desktop, and now it's starting to be moved back to the backoffice again using thin clients.

Re:The Manchurian Candidate

[Jah-Wren Ryel]

The only argument I've seen is the lack of network transparency, often poorly worded with no actual technical argument behind it.

Sounds like you aren't interested in hearing the arguments, but I'll try. Practically all X11 apps can run remotely - the ones that can't are likely to be inherently limited, like video players or 3d first person shooters that have bandwidth and latency requirements that are transport constrained. Outside of those types and pathological configurations, remote X11 just works for all apps.

V) "Wayland can't do remoting." Wrong. Wayland should be BETTER than X at remoting, partially do its asynchronous-by-design nature. Wayland remoting will probably look a like a higher-performance version of VNC, a prototype already exists. And this is without us even giving it serious thought about how to make it better. We could probably do better if we tried.

"We haven't given it serious thought" is a particularly bad approach to convince people to quit bitching. Show us a well thought out plan to support per window/application remoting, not vnc-style desktop remoting and that will shut up practically everyone. Act like you really don't give a shit and nobody will have any confidence that it ever will "better than X."

Re:show me hello world on my own pc or STFU

[laffer1]

My Mac has X on it. It came with OSX as an optional install until recent releases and it's still a free download.

Mac doesn't necessarily mean no X. In fact, some programs REQUIRE IT like some high end math stat programs.

do it without X installed

[decora]

congrats you missed the point

Re:do it without X installed

[Barsteward]

you've not made any reasonable point yet so he missed nothing

are you running X?

[decora]

if you arent running without X, then you arent running without X.

  you missed the whole point of my rant

i dont have a raspberry pi

[decora]

which is why i said 'on my desktop PC'. which has a user base of, oh, several ten-million

not some niche little fad product with 512mb of RAM that has a month waiting list so hipsterss can pretend they are saving money

Re:i dont have a raspberry pi

[Microlith]

I see you were never interested in having an honest discussion. Rather, you were waiting for a response of any kind so you could lash out angrily and move goal posts.

I dont have a raspberry pi

Which is in no way relevant.

not some niche little fad product with 512mb of RAM that has a month waiting list so hipsterss can pretend they are saving money

So beyond being a raging asshole, you ignore the fact that the Pi runs Debian, same as the desktop, and has a Weston build targeted that works right now.

Re:The Manchurian Candidate

[Coryoth]

I've seen demos of Wayland that had per window remoting, including moving and cloning per window across different diplays. Wouldn't it be nice if xmove still actually worked for most applications? If you could just move your application across Xservers as you wished and didn't have to worry about temporary network outages killing you application? Well apparently Wayland can do that. So it seems to me that Wayland has potentially more to offer in terms of network transparency than X. It isn't done yet, so let's wait and see. Everything I've seen looks very promising.

bullshit, horse shit, cow shit

[decora]

if a program cannot build easily on a standard linux machine, its not going to be adopted by hundred of millions of people and its not going to topple an installed standard with a huge userbase

the 'user is wong' attitude is what doomed every display system before and will doom wayland just the same.

get the thing to compile out of the box or dont ship it. a simple philosophy. we have cmake, autoconf, scons, choose your poison

Re:bullshit, horse shit, cow shit

[Gaygirlie]

if a program cannot build easily on a standard linux machine, its not going to be adopted by hundred of millions of people and its not going to topple an installed standard with a huge userbase

Average Janes and Joes won't be installing from sources, you know?

get the thing to compile out of the box or dont ship it. a simple philosophy. we have cmake, autoconf, scons, choose your poison

Compiling Firefox doesn't work "out of the box" either, yet people are happily using it. You do need to install all the dependencies, like e.g. a huge amount of devel-versions of packages to compile such, it sure ain't "out of the box" then. It ain't no different with Wayland at all.

Nice but

[nbsr]

...does Wayland run *on* an X server?

I could play with Wayland API and help it to take off but not if I have to wait 5+ years for Wayland to get X11 features and drivers.

Re:Nice but

[spitzak]

Yes the development version includes the ability to run a wayland "desktop" inside an X window. It will do this automatically if $DISPLAY is set when you run Wayland.

For me that is the only version that works. I have two monitors and I have set it up so Wayland runs a full-screen version on one of them, making testing pretty accurate and easy.

They may not like it but that is probably the way it is going to work first with full nVidia acceleration.

its a closed source non-linux system

[decora]

i mean, we might as well discuss windows and directx

Re:its a closed source non-linux system

[elfprince13]

No one said anything about Linux, I thought we're talking about X replacements for Unixes and Unix-likes.

my desktop PC is not an embedded system

[decora]

show me how to write OpenGL hello world programs for DirectFB on my desktop PC

Re:The Manchurian Candidate

[Jah-Wren Ryel]

It isn't done yet, so let's wait and see. Everything I've seen looks very promising.

I don't know what you saw, but what I just read at the cited article is that the people designing wayland have barely given it a second thought. That attitude does not deserve the benefit of the doubt.

Re:show me hello world on my own pc or STFU

[Beardydog]

I'm not worried about it, or complaining about the difficulty of installing it, as I'm aware that I'm currently not the target audience (although the Apache comment was hyperbole). Just wondering if I had missed anything, or if the current situation really was "build xwayland or gtfo." It sounds like the answer is, "build xwayland or gtfo."

Re:show me hello world on my own pc or STFU

[Requiem18th]

Actually learning that Wayland is being developed by former X developers removed most of my ancieties about it. Now I just want to know when it's going to be production ready and if it is going to support my craphics card.

shhh dont actually list facts

[decora]

you will scare the nutjobs who like to draw castles in their cheerios and tell you to go live there.

Re:The Manchurian Candidate

[Microlith]

Sounds like you aren't interested in hearing the arguments, but I'll try.

No, I'm just tired of bad arguments.

Practically all X11 apps can run remotely - the ones that can't are likely to be inherently limited, like video players or 3d first person shooters that have bandwidth and latency requirements that are transport constrained. Outside of those types and pathological configurations, remote X11 just works for all apps.

That's nice. But it's a very limited subset of how computers are used, and there's nothing in Wayland that makes it impossible to do this.

"We haven't given it serious thought" is a particularly bad approach to convince people to quit bitching.

Maybe because they know you won't even when they make an entirely point and put it in front of you? Read what he said:

Wayland remoting will probably look a like a higher-performance version of VNC, a prototype already exists. And this is without us even giving it serious thought about how to make it better. We could probably do better if we tried.

When he said "without us giving it a serious thought about how to make it better" he said that, out of the gate, it was better than X11 remoting and better than VNC remoting without them even seriously trying and that if they had, it would be even better.

It's not "we don't care," it's that "we've got it handled better than X, easily."

Re:The Manchurian Candidate

[Microlith]

Augh, bad engrish today.

Maybe because they know you won't even when they make an entirely point and put it in front of you?

should read

Maybe because they know you won't even when they make a point and put it in front of you?

that made more sense than all Wayland/MIR articles

[decora]

i have ever read.

no, thanks, Wayland, I need REAL networking

[dltaylor]

I use the networking capability of X (process on IP address X using display on address Y, same or different IP, different user) every day, all the time.

For example, I always run a X server on Windows boxes, because I can then run some Linux process on the Windows display "root" window. Productivity is higher because I don't have to switch "containers", in order to switch applications, and copy/paste is trivial.

Similarly, I can have a process in a different, more locked-down, user running on the root window of "my" desktop, toggling between applications without having "switch user", open a different VM, ...

I'll keep using X11 as long as I can.

Re:no, thanks, Wayland, I need REAL networking

[MightyYar]

I don't see why any of those things precludes Wayland. It looks like it will go the route of per-app RDP. RDP works fine with copy/paste and doing it per app should let you have fine grained control over the users those apps run as.

Re:no, thanks, Wayland, I need REAL networking

[LaughingRadish]

This is the point I've been making above and I've been getting non-answers like "it'll do X backwards compatibility" or "you can do remote desktops". I've never received an answer to this basic question of if a single application can be displayed on another machine.

Re:no, thanks, Wayland, I need REAL networking

[Crispy Critters]

Exactly, and the reply is always from the point of view of the developer. They want to talk about what style of protocol or something that remote apps will use--I don't care. I want to know whether I can run programs the same way that I do now.

A subset of people like me use their desktop as primarily a terminal to connect to more powerful servers. I want to know if Wayland will let me "ssh me@oldserver-running-X xterm" and then use the remote xterm to start a bunch of programs that open their own windows. I don't want to know how it does it, only if it will work.

If the Wayland developers don't want to commit to making something like this work, that's fine. It just means Wayland isn't designed for me. If they *are* going to make it work, I would feel more comfortable is they would come and say for certain that they are committed to supplying this functionality.

This same point comes up again and again. I think that the developers at some level don't understand the question, because there never seems to be an answer that is straightforward and pitched at the level of the user. (Not that anyone *owes* me an answer. I am just making a request.)

Re:no, thanks, Wayland, I need REAL networking

[bill_mcgonigle]

Of course it will, it's very useful.

Unless there's something preventing the implementation of a dummy Wayland server (memory backed) then (if I understand how this thing works...) starting a "remote" Wayland app would need a wrapper that would instantiate a dummy Wayland render space and some signal ssh would have to carry back to launch a Wayland client on your console side, and ssh would have to plumb the I/O. ssh would probably need a flag to start this (too bad -W is taken) and obviously somebody has to write it, but it's not like nobody wrote the code to do -X and -Y, because it is really useful.

Re:no, thanks, Wayland, I need REAL networking

[dbIII]

Currently it seems to rely too much on the local graphics driver to the machine where the app is running so I think that's why there's no answer. Oddly enough those local graphics drivers they are using are the ones that come with X, but they are abstracting everything on top in a different way.

The whole argument is about bagging a flexible modular approach and pretending an inflexible monolithic approach is going to be inherently faster so I don't think we'll get any useful answers about extra options until the argument is over and the Wayland people are willing to consider something other than a dumb framebuffer proof of concept.

Re:no, thanks, Wayland, I need REAL networking

[amorsen]

I am a bit surprised at the number of people who fight for the cause of remote X. It was IMHO a rather cool thing to be able to do on workstations in the 90's, but remote X has not evolved since. As soon as the TCP session drops, all your windows are gone. Is that really useful these days? It means you cannot bring the applications with you when you change IP address, and that is a show-stopper for me. Maybe everyone tunnels X over VPN (not SSH) to get around that.

VNC is crap, but at least you do not lose everything when the network dies.

Also, remote X performance is absolutely dreadful with modern clients. X cannot handle latency.

Re:no, thanks, Wayland, I need REAL networking

[Crispy Critters]

"I am a bit surprised at the number of people who fight for the cause of remote X."

Well, people use their computers for different things. If you have a hundred people sharing TBs of data and looking at it using massive complex home-grown analysis and modeling packages, remote X makes sense. It's the difference between shipping a few plot windows across the network vs. GB of data. (And X performance can be fine on a wired LAN when you have ping times in ms and no dropped connections. Again, depends on your own personal situation.)

Sure, this is a use case that only applies to a tiny fraction of users, but for those users it is absolutely necessary.

Re:no, thanks, Wayland, I need REAL networking

[sjames]

Will there be abnything in Wayland to make it play nice with ssh -X?

It's VERY handy to use the automatically redirected X over ssh.

Re:no, thanks, Wayland, I need REAL networking

[sjames]

So it sounds like the issue gets pushed off to the ssh developers to implement (or not).

That seems to be the problem everywhere. The same thing happens with the libraries such as GTK.

Re:no, thanks, Wayland, I need REAL networking

[bill_mcgonigle]

So it sounds like the issue gets pushed off to the ssh developers to implement (or not).

Like X forwarding got pushed off on the ssh developers? Or is somebody still doing X in the clear in 2013?

Re:no, thanks, Wayland, I need REAL networking

[sjames]

It was possible to do over X with or without the -X convieniance option by specifying a tunnel nd manually setting the DISPLAY variable.

The description also sounded like ssh would have to take a much more active role than just maintaining a tunnel and setting an environmment variable.

Re:no, thanks, Wayland, I need REAL networking

[MightyYar]

I imagine ssh would implement the new feature, or you'd use a stand-in. For instance, call an "xterm" with an rdp command. It's all theoretical at this point :)

Re:no, thanks, Wayland, I need REAL networking

[k8to]

There are solutions to these problems. xrpa is one of them.

It doesn't look much like the X protocol, but that's fine.

Re:no, thanks, Wayland, I need REAL networking

[bill_mcgonigle]

The description also sounded like ssh would have to take a much more active role than just maintaining a tunnel and setting an environmment variable.

From what I understand, there's still lots of work to be done, it's pre-alpha. As I understand it, to do a remote window requires a local Wayland server to run to handle the drawing space, and then the client side has to consume VNC-like updates across the communications channel.

Ideally the wayland app's init routine will recognize $DISPLAY or some other variable and start that for you. But one can imagine a wrapper script or LD PRELOAD that ssh could involve that would do that too. On the client side, ssh could set everything up, but it might be a better separation of concerns to have a client-side script get fired off when ssh makes such a connection. Perhaps such a mechanism could even be genericized to the point of wayland being a specific case implementation of a tunnel/client-setup/server-setup arrangement.

I'm not sure that its xauth handling is relevant at that point. I think the ssh-agent stuff is handled below X.

Just to be clear, this is just based on what I've read - I don't know the Wayland line protocol. But I don't get the idea that people think this would mean the end of remote windows or that the openssh folks wouldn't support an additional display technology.

Re:no, thanks, Wayland, I need REAL networking

[sjames]

I think most of the concern is that the whole thing feels tacked on as an appeasment but with little work to make sure it can actually happen. To me, it seems like an important enough use case to put a bit more effort into making sure the underlying APIs are at least friendly to doing all of this efficiently.

One concern is the flow of input events back to the remote app.

I would be a lot happier if the wayland protocol simply included a proper RPC protocol so a remote app could just connect through that. Thaat could still be proxied if necessary for greater efficiency, but would at least leave it working for the default case.

It's not so much a question of can it work (if you don't mind terrible performance, even shared memory with multiple threads over TCP/IP can be made to work) but will it work well.

Re:no, thanks, Wayland, I need REAL networking

[sjames]

And that's the problem. Too much handwaving and assuming someone else will fix it for them later.

Re:no, thanks, Wayland, I need REAL networking

[MightyYar]

No, I don't think that's the problem at this stage. The problem at this stage is that Wayland is not far enough along to use, network transparent or not. I don't think they are handwaving so much as saying they aren't really ready for that yet and they don't see why it will be a roadblock. I agree - I mean, RDP is proven and works at the application level (you can do it on Windows right now if you want). There are open RDP clients. There has been demonstration code that shows that Wayland will work with RDP. Modifying SSH to open a few ports for your RDP client to poke through should be literally trivial... you can already do it with -L, AFAIK. The only issue I could foresee is patents, and that's not really a technical issue.

Re:The Manchurian Candidate

[Jah-Wren Ryel]

Maybe because they know you won't even when they make an entirely point and put it in front of you? Read what he said:

I read that everything he said was qualified with the word PROBABLY. What did you read?

Re:watch out they will accuse you of FUD

[Microlith]

The only "asshole" here is you. Just look at your mad ranting.

Re:The Manchurian Candidate

[Microlith]

I read that everything he said was qualified with the word PROBABLY.

Ah, yes because he said "we could probably do better" it's instantly terrible and doomed.

What did you read?

I read it as someone who was confident of their solution but unsure of the final form, believed that their prototype implementation was already better than X11/VNC, and acknowledged that there was room for improvement but wasn't sure how much. You read it as "we don't care" and I'll wager that if anyone here is off base, it's you.

Re:The Manchurian Candidate

[MightyYar]

Here you go!

Re:The Manchurian Candidate

[mark-t]

Wayland doesn't even support remote rendering anyways, so you can't render on a different system than the one running the application.

Re:The Manchurian Candidate

[Jah-Wren Ryel]

Ah, yes because he said "we could probably do better" it's instantly terrible and doomed.

Hyperbole considered bad.

I read it as someone who was confident of their solution but unsure of the final form

"Probably" was not the only qualifier in the paragraph, pretty much everything he wrote was explicitly qualified. However you are welcome to support your beliefs with a citation to some documentation for even alpha level protocols for remoting wayland apps.

What I've seen is stuff like this GSoC participant who discovered that its not as simple as he thought. No one's touched his work since. Seems like the only work to come since then has been RDP based DESKTOP forwarding, not application remoting.

Re:The Manchurian Candidate

[Jherek Carnelian]

Ah, yes because he said "we could probably do better" it's instantly terrible and doomed.

That is not what he wrote at all. It is right there for all of us to read. And this from the person who complained about being tired of bad arguments? Did you really mean being tired of resorting to bad arguments?

"Wayland remoting will probably look a like a higher-performance version of VNC,"

Re:The Manchurian Candidate

[Microlith]

I'm mocking him. He sees a tiny bit of uncertainty in the guys comments and reads it as if the guy is completely blowing off remote access when it's obvious that he's not.

Re:The Manchurian Candidate

[Microlith]

Hyperbole considered bad.

What, I can't be sarcastic?

No one's touched his work since.

Looks like he hasn't touched his other projects either.

Seems like the only work to come since then has been RDP based DESKTOP forwarding, not application remoting.

And RDP supports rootless forwarding just like X11. But that's just one possible way of forwarding them. It's not like its impossibe.

Nothing is stopping you from continuing to stick to Xorg, of course. Wayland won't fully displace X11 for a while.

Re:The Manchurian Candidate

[Jah-Wren Ryel]

Looks like he hasn't touched his other projects either.

(A) He tried it and wasn't as simple as all the big talk
(B) no one else has picked it up.

And RDP supports rootless forwarding just like X11.

Bit-blasting just trades the latency problems with X11 forwarding for bandwidth problems.

  But that's just one possible way of forwarding them. It's not like its impossibe.

"Not impossible" is a far cry from being designed, much less implemented.
That's a tacit admission on your part that work is not being done on the issue.

Re:watch out they will accuse you of FUD

[caseih]

I don't understand why you are making a big deal out of building wayland. X11 is very difficult to build (took hours the last time I did it). Who cares? When it's ready, you will be able to install it with aptitude install wayland. Building from source is always more complicated than installing from a binary package. This has nothing to do with support. why the attitude?

Re:The Manchurian Candidate

[Coryoth]

They have barely given it second thought because they've established that it can be done in principle, and it isn't the stuff they're working on (which is getting the actual display working cleanly and efficiently). They can worry about it when they've gotten the fundamentals pinned down. Do you really want excellent networking for a display system that doesn't display well, or is horribly slow? First things first and all that. As long as nothing they do makes it infeasible, or overly complicated there's no point in worrying about it till the very core functionality is working as they wish.

Read TFA

[loonwings]

Yep. That's whatever they're talking about for them.

Input Isolation?

[bill_mcgonigle]

Anybody know if Wayland is doing something sane about input isolation? It's really bothersome that X allows every other X app to steal my keystrokes. Want my root-privileged sudo password? Just get me to run some malicious X app. Is there a malicious keystroke logger in Google Earth? Who knows.

Re:The Manchurian Candidate

[RightwingNutjob]

I haven't delved deeply either, but I've had cause and occasion to casually study the code. Compared to some things I've seen, it certainly screams Legacy Cruft in a few places, but by no means does it reek of unmaintainability.

Disabling compositing?

[Windwraith]

My main concern about this is that the desktop seems to be accelerated all the time. This is fine and dandy when you do general work, web browing and such, but if you play or develop games, it makes a slight difference. For example a quick blinking effect might get obscured somehow by the compositor slowing things down. This is more of a concern when developing, sure, but it's something I can do *now*.
Either unaccelerated window managers or KDE which allows dynamic turning off the desktop acceleration are good solutions, but what happens when everything gets composited no matter what, as it seems to happen with Wayland? I don't think not compositing full-screen apps is a good solution either, as you might play or test in a window for convenience...

you didnt even read what i wrote

[decora]

and then felt the need to lecture me about how i was wrong.

i want to run non-X hello world wayland on my PC.

that doesnt mean raspberry pi. it means my PC.

PC. the thing sitting on my desk.

i suggest you read the record back

[decora]

i wrote a brilliant rant about how this shit doesnt work. you failed to appreciate it and chose to lecture me about some bizarre toy product that has nothing to do with my points.

Re:i suggest you read the record back

[Harik]

You wrote that you're too stupid to get apache working on your machine, and you expect us to give a fuck that DEVELOPER TESTING software isn't a one-click install for you?

because im sick of all the lies man

[decora]

this shit doesnt work, people keep saying it will replace everything.

they call anyone who challenges them purveyors of "fear uncertainty and doubt.

FEAR - im afraid it doesnt fucking work

uncertainty - im uncertain if i should spend 40 hours porting my shit to this 'next big thing, or ubuntu's MIR, or ubuntu phone's ShitFlinger or whatever teh fuck its called.

Doubt - I Doubt anyone will ever write a game for linux if this is the fucking situation with the graphics layer - 4 to 5 different subsyetems with incompatable versions and all of this hoopla and bullshit and douchebaggery.

its fucking irressponsible, its shit, its like taking a giant snowjob and blowing it all over the open source community.

Re:because im sick of all the lies man

[Barsteward]

take a pill and go lie down, your in a state of delusion

Re:X's shortcomings

[JDG1980]

Many of X's recent "everything as pixels" shortcomings and network bottlenecks came to be because the exact same developers who are pushing to abondon X11 tried to make it into iPhone graphics. That didn't work very well and so they decided to abandon it in favor of the Wayland rewrite. Which is ok, fine, they can work on whatever they like. But when the same exact developers justify thier work with the statement that X is broken, and they're the bloody ones that broke it and abandoned it what way in the first place, it just pisses me off.

Translation: X11 works fine if you're willing to party like it's 1985, with bitmap fonts and non-anti-aliased Bresenham lines.

That might work if you're administering a server, but for a desktop environment in the modern world, it's a sick joke.

No, they don't know any better or are any smarter than the decades of programmers that came before them culminating in the cumulative end product known as X. They want their pet desktop-as-a-iPhone use case to work perfectly at the expense of all that other stuff they don't personally use. Classic case of young developers only thinking of their own needs and lacking the imagination or experience to see past themselves.

First of all, the people working on Wayland are in many cases the same people working on X11. It's not that they are necessarily smarter now, but they are more experienced. X11 was written in a different time, for different systems, to solve a different set of problems than what we have now.

And regarding your accusations, I'd suggest looking in the mirror – your willingness to tolerate 1980s-level graphics is a lot more of a "pet" use case than what Wayland is attempting to provide.

Re:show me hello world on my own pc or STFU

[peppepz]

Huh? Because I think that X is not dead yet? You're reading too much in my comment.

Re:The Manchurian Candidate

[g1zmo]

xmove was around for forever, while xpra is the latest gen implementation. Why would you claim that they don't exist?

Re:The Manchurian Candidate

[adolf]

If it behaves anything like a "high-performance" VNC, I'm not interested.

VNC is not a network-transparent display. It is a glorified remote framebuffer.

I thought we gave up on dumb framebuffers a long, long time ago, with the first accelerated X server (or Windows 2 or 3 or whatever it was).

One can still configure an X server today to work as a dumb framebuffer, or Windows for that matter Nobody does that. It is lousy and slow. Nobody wants this shit if they have a choice in the matter.

If its networked display options were described as a "high-peformance RDP," I'd be interested in learning more. But it is not.

(For those still living in Mom's basement, both RDP and X are tremendously more useable over a LAN than VNC will ever be capable of.)

NOT a misconception

[dbIII]

A major problem is not whether Wayland supports old X applications but instead that new Wayland applications are not going to be network transparent like X ones. That limits them to one to one network connection via third party hacks like VNC instead of the many to one and one to many options that X gives you.
It's a backwards step to the non-networked, single user, single platform mindset. That's not even what people are looking for in gaming consoles any more.

The ramifications are that new wayland only apps are only going to be useful if you are sitting right in front of the computer you want to use - an insane restriction now that phones and tablets with wifi are at the point where they can be effective terminals to a desktop computer doing the heavy lifting (video, graphics, voice recognition whatever).

The single platform restriction also sucks - linux only due to a deliberate design choice.

Sorry kids, a dumb framebuffer is not a new idea and a trip back to the 1970s has got to be justified with new features and good benchmarks before it can be proclaimed as better. For now there's only stupid block diagrams that pretend any internal complexity and internal communication is faster than something with more blocks in a diagram even if they are a lot simpler - it's just smoke and mirrors without benchmarks.

Even calling it Metro for linux at this point would be giving it too much credit - save the hype for when it delivers on a performance promise and has more features than SVGAlib from 1995.

Re:NOT a misconception

[melikamp]

A major problem is not whether Wayland supports old X applications but instead that new Wayland applications are not going to be network transparent like X ones. That limits them to one to one network connection via third party hacks like VNC instead of the many to one and one to many options that X gives you. It's a backwards step to the non-networked, single user, single platform mindset.

You want network transparency? Why does the display server have to provide you with it? You want to drag networking, authentication, and encryption code/hooks into the display server. So much for the UNIX philosophy. There is already a "network transparency" protocol which your applications can use: https+xhtml+javascript. Fire up the transmission Web server/client to see a stellar example. You will never, never, never obtain the efficiency and the responsiveness of a Web app through the display server. A cutting-edge Web app can do real-time 3d-rendering, for chrissake, and anything with just forms and dialogs will fly like a jet. So if supporting old X applications is not a problem, then there is no problem. The X's approach to gaining network transparency is just plain wrong, and I say it as a user. Using X's "network transparency" to run a GTK or QT app across the Internet is every bit as annoying as running it over VNC, and is often slower. I hope to god Wayland will take off and GUI app developers will become aware that they are in the best position to provide network transparency. It's easier for them, as writing Web interfaces is arguably easier than using a toolkit, and it's obviously better for users.

And if you are stuck with the software that (1) has no shell interface and (2) insists on using a modern toolkit such as QT for rendering 3D widgets to a local screen, then you are stuck with an application which is not intended by the authors to be network-transparent, and Wayland isn't designed to solve this problem. Wayland is for drawing pixels to a local screen. Give it the right kind of app, and it will render it a browser window with 3D shadows, animations, and anything you bloody want, with no tearing, no flicker, no lag of any kind.

Re:NOT a misconception

[amorsen]

I have a Linux XBMC HTPC connected to my TV and I have a Linux laptop. Tell me how I can control my HTPC from my Linux laptop using X. Opening a new XBMC on the HTPC with the display remoted to my laptop is not particularly useful, especially when doing so loses all hardware video acceleration. Even running a 3D game that way does not work, for the same reason. The use cases you are proposing are not handled by X today, so your implication that Wayland is a step backwards is unfounded.

Using tablets as X terminals does not really work anyway, as the risk of losing all windows due to a connection interruption is too great.

Re:NOT a misconception

[dbIII]

Why does the display server have to provide you with it

Because the Wayland people are saying better than X in every way, so I'm asking them to put up or shut up with the hype and just discuss their own application on it's own merits.

Re:X's shortcomings

[dbIII]

That might work if you're administering a server, but for a desktop environment in the modern world, it's a sick joke.

Details please. We get enough unfounded sound bites from bent politicians and I'm sure you are a better person that that.

First of all, the people working on Wayland are in many cases the same people working on X11

No, there's just that one guy that started Wayland after doing a bit on an X module. Keith Packard saying "good luck" to him is not "working on Wayland". Raster adding Wayland support to a widget set in e17 isn't really working on Wayland either.

Re:The Manchurian Candidate

[dbIII]

I've seen what happens when you run X11 apps on windows.

And I see it five days a week with about a dozen people doing it with no problem since they are not using XFree86 from the year 2000 on MS Windows but something a bit more recent that supports shaped windows.

Let's have some real stuff

[dbIII]

In the article the "what's wrong with X" has a "Theoretical Example" so doesn't actually find something wrong.
Let's have some honesty, some real examples, some real benchmarks instead of advertising type "spin" and empty promises about what might happen later.
Let's have a real article about what Wayland is really doing now instead of another stupid and pointless "X sux" bit of shit.

There isn't even a screenshot.
The article may as well be about something that doesn't exist.

Re:Let's have some real stuff

[remi2402]

A couple of benchmarks have been done over the past 2 decades. Though it's a shame they're not mentioned in the article.

The reference paper on the topic is Keith Packard's and Jim Getty's USENIX 2003 paper on LBX (Low Bandwidth X), a compression proxy for the X protocol. This paper compares LBX against the standard X protocol (both with and without a compressed SSH tunnel). A couple of key findings from the article:

• SSH compression is almost as good as LBX (which is probably why nobody bothers with it)
• X11 is pretty efficient on bandwidth for everything except raw image data
• X11 is very sensitive to latency

Now some of those issues have been (somewhat) mitigated in various libraries such as xcb, Qt and Gtk+, X11 can only be used comfortably over low-latency links.

While searching for that first article, I came across a more recent presentation which compares X11 against VNC and NX. Again, the author(s) conclude that X11's performance suffer greatly whenever latency increases. As for my own daily experience working company X terminals, remote X even on speedy gigabit networks is a major PITA and I'm planning to work on comparing alternatives (VNC, RDP, SPICE, ...)

X still has value, it's the lingua franca of GUI protocols on UNIX and I don't think anyone expects it to disappear anytime soon. But it is an antiquated protocol, both for local operations and for remote displays.

Re:Let's have some real stuff

[dbIII]

Are you for real? Wayland Benchmarks and direct comparisons instead of hype.

And piss off with the "antiquated" crap when comparing it with Wayland's even older idea of a dumb framebuffer.

Re:The Manchurian Candidate

[mpol]

And this would be a possible roadmap for X12:
X12 Development
Reading that list also makes a big argument against X11, and it seems to me that Wayland will be the place where lots of things will be better.

Re:The Manchurian Candidate

[shia84]

Give me a dumb framebuffer _with_ network transparency and I'll happily shut up. If they finalise the design and only tack on networking afterwards, it'll be probably less efficient than it could have been.

I for one want them to prioritise it during the earlies phases. They are telling me (indirectly) that they probably won't do it at all and leave it to someone else. That's fine, but also means Wayland is designed to not be used by me and people like me. And when distros start pushing it as default, there will be a big ruckus... I'd rather them to be sensible and support network transparency at least as well as X11 does, and that it "just works" the first time I have a Wayland server in front of me, for all applications that don't have Wayland releases (and obviously the new ones too).

Re:The Manchurian Candidate

[EMN13]

That depends on what kind of slowness they mean - bandwidth, or latency? I don't think X dealt well at all with medium-to-high latencies, so that's perhaps what you're seeing.

Re:Run VNC then

[xiando]

run VNC. Some of us want a fast responsive GUI that doesn't rely on 30 year old protocols.

Run VNC? Do you even understand how people use X? I guess not. I ssh into another box & run some program and up it pops on my local screen. Quick, easy, simple, works. Now, setting up VNC works in some cases, but now we are talking about something completely different and completely different use cases. You have some server somewhere, you want to run a GUI config program or whatever real quick, you just type the command and it works. You do not want to spend 15 minutes installing all sorts of VNC crap, configuring it remotely and locally and so on when you're already done in 30 seconds with todays X. I think you simply don't manage or use remote boxes.. atleast you've made it clear that you simply don't get it.

Re:The Manchurian Candidate

[DrXym]

If the protocol was fine we wouldn't see a number of products trying to do an end run around it - NX / FreeNX, RDP, VNC. Nomachine's site in particular has plenty of info explaining precisely why X is so crap and why NX shims the transport with its own protocol to eliminate roundtrips and redundancy.

Re:The Manchurian Candidate

[roscocoltran]

Which is a definitive show stopper for me. I'll stick with X.org then. I want to run this remote "system-config-lvm" on my local desktop.

Re:The Manchurian Candidate

[gmack]

Mark-t hasn't been keeping up to date

Re:The Manchurian Candidate

[Lemming Mark]

xpra is nice, although it'd be even nice to see an existing window manager / compositor provide support for remoting windows using the xpra protocol - I'm not aware of a reason this couldn't work, since the xpra server just works by being a compositor anyhow... This would give me the ability to grab arbitrary windows from my desktop and display them on other machines, whilst having them run at full speed locally - that would be a big improvement on remote X11, for my uses.

Also, I'd like to see Wayland support the same. In some ways, although I'm not worried about remoting being available on Wayland, I do wish there was a central place for common Wayland remoting implementations to live. AFAIK that doesn't exactly exist at the moment, other than de-facto in their demo code - and given various desktops are going to be implementing their own compositors, I don't know that they'll inherit these implementations conveniently... Hopefully I'm just lacking reassuring information and it'll all be OK.

Re:show me hello world on my own pc or STFU

[elfprince13]

I have X too, but we're in a tiny minority of Mac users. Apple no longer even gives resources to develop their own X11.app and tells everyone to use the third party XQuartz instead.

Mir?

[ndogg]

I know everyone here loves ragging on Mir, but it wasn't even brought up in the article, so why was it even mentioned in the summary?

Re:show me hello world on my own pc or STFU

[iggymanz]

I'm only considering percentage of all desktop systems in use. the domination of finance, science and engineering desktop by unix workstations with X11 which peaked in the 90s has declined while home pc use has skyrocked.

Architecture & Remoting

[mike.mondy]

Seems like a bit of FUD on both sides of the argument...

A while back, I spent a few minutes skimming the Wayland FAQ and Wayland Architecture Diagram. Interesting stuff, especially the architecture page, and they provide actual detail while the TFA mostly doesn't.

For comparison of the two architectures, when running X, you might have an ordinary window manager or you might have a compositing window manager. The Wayland model is that Wayland *is* a compositor that provides both window manager functions and some of the functionality of an X server.

From what I can see, here's the architectual differences between X and Wayland when it comes to supporting remote app display:

Intentionally misstating by being over simplistic, it sounds like the reason Wayland doesn't support remote displays is because it also doesn't support local displays! More accurately, Wayland supports local displays (of course), but unlike X11 provides no way to render to them. Wayland doesn't do rendering; it apparently "just" knows how to swap video buffers to a display device and coordinate buffers between multiple clients.

I'm thinking that, for example, if you want to write a graphical app, you might target OpenGL or cario and then expect your code to work in both Unix (with X) and on Windows (without X). With Unix/X, I'd expect an OpenGL library that handed X primitives to the X server. With Wayland, you'd apparently have an OpenGL library that rendered to a buffer and then handed the buffer off to the Wayland compositor.

So, Wayland isn't doing some of the things than an X server would do. Wayland is never working with drawing primitives. It seems obvious that you'd never be able to run apps that use the old X toolkit libraries against Wayland without an X server in the picture. And, both the TFA and the FAQ report this and note that you'll need X server(s) in addition to Wayland for the foreseeable future. The X server(s) talk to Wayland instead of to hardware.

There's going to be support for running Wayland apps remotely. However, as others have noted, an obvious question is how efficiently a "native" Wayland app could be displayed remotely. If the app and its libraries are rendering graphics primitives into display buffers, it seems obvious that low level primitive operations are lost by the time Wayland gets the buffers, so you have to be able to efficiently transmit bitmap deltas. Queue arguments re whether drawing primitives are more efficient or bitmaps are more efficient...

The discussion of doing remote Wayland apps seems to revolve around how to transmit the per-app buffers across the network instead of handing the buffer to the local Wayland compositor / display driver. Or perhaps about having the compositor know that certain app buffers should be transmitted instead of composited to the local display, but that's almost the same thing when viewed as a flow.

Transmitting bitmap deltas works pretty well, but for some apps, sending higher level information such as the original OpenGL might be better. With X, they defined an extension, GLX for essentially passing the OpenGL to a remote server. Similarly, I imagine it would be useful if an OpenGL app could talk to a remote Wayland server instead of sending bitmap deltas. So, it looks to me like it would be useful to define an extension mechanism for transport that would allow OpenGL commands to be sent to a remote computer where they could be rendered to a remote buffer and handed off to the remote Wayland compositor. Bonus points if the extension mechanism is generic. Seems like transport of audio might be another fit for a modern replacement of X.

Not an X server developer nor a Wayland developer. I may have garbled things somewhat, but perhaps someone could clarify the mistakes and help take a portion of the FUD out of the

Re:The Manchurian Candidate

[Coryoth]

There was a time when displays did everything by passing around rendering primitives -- lines, rectangles, black and white bitmap pattern tiles. At that time it made a lot of sense to integrate network at the low level because you had to figure out how to send and decode all those drawing primitives over the wire.

Display technology moved on. Displays became rich and complex and colourful, and different applications had very different needs and took on more and more of the rendering task themselves and simply pushed bitmap buffers to the display system. Now the task of the display system was to mediate and manage and request complex bitmap buffers from the various clients.

At this point remote display was a matter of having the client send (potentially compressed) bitmap buffers -- let the clients do their own rendering. This is how most remote display systems written in the last 15 years do it. Indeed, that is how X does it these days for most applications: the applications do their own rendering via GTK or QT and Cairo and X pushes the pixmaps down the wire.

If all you are doing is throwing around bitmap buffers, and the display software is simply mediating and displaying those, then remote display doesn't need a whole lot of thought at the display level -- all it has to do is mediate and display the bitmaps it gets from clients. Now, providing a remoting system to let remote clients get their bitmap buffers to the display when requested ... well that's still a thing that needs to be done, but it the base display software doesn't have to care too much about how that gets done.

Think of it as teasing out the layers in the software. The base layer is pushing pixels to the screen (no matter where the data for those pixels came from, remote or local). That's one job: pixels on screen. Focus on that and do it well. Another job is getting the data that the base layer is going to display to it, and you can worry about remote/local differences in that layer.

Re:show me hello world on my own pc or STFU

[phantomfive]

SurfaceFlinger. Of course, no one has actually adopted it. It's just prevalent because of Android.

And they keep making backwards incompatible changes to SurfaceFlinger. If you're planning on using SurfaceFlinger, I suggest waiting until it's a more mature technology.

Re:In other words

[gagol]

"We're aware networking is important for you and rather than focusing on this single issue, we have implemented a poc with no effort. We are confident to make the experience way better than want X11 or VNC can offer you at the moment."

Feel free to help if you feel they dont code fast enough.

Re:X's shortcomings

[Anonymous Coward]

ts; dr...

RTFA

[Anonymous Coward]

I know this is Slashdot and reading TFA drops your street cred to zero, but if you're going to comment on the article then you should have some idea of what it says.

Summary: X11 is not network transparent anymore. It was in its original conception, but in practice that stopped being true a long time ago.

Re:The Manchurian Candidate

[goose-incarnated]

There is no need for a well thought-out plan. It's agile.

Re:The Manchurian Candidate

[Harik]

Outside of those types and pathological configurations, remote X11 just works for all apps.

So running an app over the internet is a pathological configuration?

X11 is utterly garbage at remoting because it was never designed for it, it was designed for LAN use with near-zero latency. That's why the calls are syncronous.

Sure, it's possible to forward an X11 connection across 100+ ms of latency, but I wouldn't call the resulting clusterfuck 'usable'. There's a reason that the nX library is used to make it reasonable - and there's no reason that you can't do the same with a different library that's not inherently constrained by a 26 year old design with no concept of high-bandwidth/high-latency connections.

Per-window RDP is utterly trivial to implement and works better on modern connections than X11 ever has.

Re:The Manchurian Candidate

[Harik]

You're frankly too stupid to even cater to. Wayland (nor Xorg) get to dictate how the apps you want to use are written. Since basically everything now is doing the rendering themselves and pushing bitmaps, X11 is terrible at remoting. If you have control over your app then make it remote properly yourself.

Otherwise shut up and stop trying to tell the rest of us that running a text editor from 1992 is the be-all-end-all of remote graphical work.

Re:Run VNC then

[amorsen]

Luckily GUI config programs are going away. Most things can be configured either on the command line or through HTTP.

Keeping remote X around just for the sake of Oracle seems a bit excessive. Someone else suggested system-config-lvm as a reason -- if Red Hat Linux has evolved to the point where we need GUI utilities just to do disk management, it is probably time to switch to something better.

Re:The Manchurian Candidate

[mark-t]

It's my understanding that such projects are not part of the Wayland project itself.

Re:The Manchurian Candidate

[sjames]

That's nice. But it's a very limited subset of how computers are used, and there's nothing in Wayland that makes it impossible to do this.

Those of us who use X that way are not inmterested in 'not impossible', there's lot of things that aren't actually impossible out there.

We are interested in the capability being a core design goal. If it is, then fine. If not, we will not be hopping on your bandwagon. It's really that simple.

'Not impossible' is far cry from having it handled. An end to war, poverty, and opollution is also 'not impossible'.

I did read but disagree with that point

[dbIII]

It's an example of where the article evades the issue and in nearly every case it still is network transparent anyway. If fact I can't think of an example where it isn't (even 3D games run remotely over X if you have decent graphics hardware at the display end).
Personally I see it as setting up an excuse for Wayland being tied deeply to the hardware, giving up on flexibility and pushing a lot of hard work back at the people writing the applications. IMHO it's a step backwards since the application writer has to consider implications of things like multi-monitor setups with different resolutions instead of Wayland taking care of it for them.

Don't blame X for crap hardware and ignorance

[dbIII]

especially when doing so loses all hardware video acceleration

Then how about having decent hardware video acceleration on the end where you want to display it or VirtualGL if the good hardware is at the other end of a network pipe to where you want to see it?

Both work.

The first I was doing in around 1999 and the second a couple of years ago.


This ignorant "X sux" bullshit as part of hype for a project that should instead stand on it's own merits is annoying.

I'll wait until 10^5 bugs filed, are closed on it.

[bbsalem]

Backward compat would be nice, proven claims of performance would be nice, but nicer still would be that whatever it replaces that lots of bugs that have been opened on it and are closed. Only then will I be convinced that it MIGHT be worth it to switch from X11, and there had better have been backward compat all along so that all my legacy apps run in the meantime, Anything less is empire building, and judging on how well Ubuntu is maintained, that is a hard sell to me.

Serious responses only please

[dbIII]

There is already a "network transparency" protocol which your applications can use: https+xhtml+javascript ... You will never, never, never obtain the efficiency and the responsiveness of a Web app through the display server

Web browser with javascript versus X, or VNC, or RDP, or just about anything? Are you still in school or are you attempting to play some sort of joke I just cannot see here? I was running interactive 3D applications over X with no apparent lag from a server in the next building using a desktop machine with a 4 megabyte video card in 1999 that was performing better than you'd expect with https+xhtml+javascript on a fast desktop machine now.

Wayland is for drawing pixels to a local screen

Which creates too much hard work for the application writer IMHO. See other posts for bits about dual monitor setups with different orientations or resolution, positioning of popup menus and other issues due to it being tied down hard to the hardware.

Re:The Manchurian Candidate

[aaron552]

Unless you're using applications that don't use GTK, Qt, Cairo, etc. you're already doing remote a framebuffer over X.

Re:The Manchurian Candidate

[adolf]

Seriously?

Well, then, allow me to retort that I don't like X much these days, either.

FFS.