Wayland - Beyond X (The H)

[Posted February 13, 2012 by corbet]

The H has posted a lengthy introduction to the Wayland display server project. "Wayland is only as useful as the applications and toolkits it supports. Applications built for Xfce, GNOME and LXDE use the GTK+ toolkit. Porting the toolkit to Wayland makes the use of Wayland transparent to the application. From an application's point of view, it is still using the common UI elements, buttons, scrollbars, text areas, sliders and checkboxes, that it has always used; but further down the graphics stack, in the backend, these are now translated so they are rendered with an appropriate graphics library into Wayland buffers."

to post comments

Wayland - Beyond X (The H)

Posted Feb 13, 2012 21:23 UTC (Mon) by JohnMorris (guest, #73531) [Link] (252 responses)

X's great strength is network transparency. I'm not up to speed on Wayland: does it / will it have the same abilities?

Wayland - Beyond X (The H)

Posted Feb 13, 2012 21:29 UTC (Mon) by dlang (guest, #313) [Link] (155 responses)

No, depending on who you ask network transparency is either a feature that's not needed in today's world, or it is something that they will look at adding to Wayland later on (i.e. submit the patches)

There is some talk that you may be able to run a X server inside Wayland.

overall it doesn't look good in terms of the network access as far as I can see.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 21:48 UTC (Mon) by Company (guest, #57006) [Link] (30 responses)

I think the common answer is "VNC is better than X anyway."
And VNC will work fine with Wayland.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 21:59 UTC (Mon) by valyala (guest, #41196) [Link] (12 responses)

VNC eats a lot of bandwidth. NX is much better in this respect - http://en.wikipedia.org/wiki/NX_technology . But it looks like NX won't work well with Wayland.

NX dead end?

Posted Feb 14, 2012 8:17 UTC (Tue) by amtota (guest, #4012) [Link] (11 responses)

NX does seamless windows which is great, but it is also closed source nowadays (v4.x onwards), and although v3.x is open-source it is not longer properly maintained.
Try http://xpra.org/ (which I maintain and does seamless windows and more)

NX dead end?

Posted Feb 14, 2012 9:09 UTC (Tue) by sitaram (guest, #5959) [Link] (7 responses)

How old is this project? Why doesn't it get more attention? Why haven't I heard about it till now? Why Why Why???

In one shot you solve one of my biggest problems (long story...) and I only find out because I happened to read all the *comments* on a story?

How old is this project? Why doesn't it get more attention? etc

Posted Feb 14, 2012 10:09 UTC (Tue) by amtota (guest, #4012) [Link] (5 responses)

> How old is this project?
The original version (this is a fork) was started sometime in 2008 by Nathaniel Smith, the earliest reference I can find on LWN is http://lwn.net/Articles/276855/ - "Announcing xpra v0.0.4" - April 2008. I've spent the last 3 years actively improving/packaging/supporting it.

> Why doesn't it get more attention? Why haven't I heard about it till now? Why Why Why???
Because I spend my time trying to make it work better (coding mostly), not writing press releases? Although I should probably do a bit more of the latter..

> In one shot you solve one of my biggest problems (long story...) and I only find out because I happened to read all the *comments* on a story?
Glad it helped.

How old is this project? Why doesn't it get more attention? etc

Posted Feb 14, 2012 11:34 UTC (Tue) by Cato (guest, #7643) [Link] (4 responses)

Sounds really useful, particularly since you have a Windows port and I often need Windows to Linux interoperability.

Please send announcements of new releases to LWN and Freshmeat (now Freecode) at least - that would get you a lot more visibility and not take much time.

It would also help if you mentioned on the site the key words 'remote access' and that you cover a similar problem space to NX (and to some extent VNC) - it's not clear from the xpra site that it works well over low bandwidth connections. Also useful if you mention that xpra over SSH is supported - it's given as an example but mentioning it as a feature would be good.

How old is this project? Why doesn't it get more attention? etc

Posted Feb 14, 2012 14:02 UTC (Tue) by amtota (guest, #4012) [Link] (3 responses)

> Please send announcements of new releases to LWN and Freshmeat (...)
Will do for LWN, problem is that I tend to do one or two releases a month and don't really want to spam LWN.. The original (unmaintained) version is on freshmeat so unless I rename this fork, I can't update that.

> (..) mentioned on the site the key words 'remote access'
> Also useful if you mention that xpra over SSH is supported
Both done, also added more info to the home page. Thanks!

> it's not clear from the xpra site that it works well over low bandwidth connections
It's OK, I've added some info to the site. FYI: on localhost and using mmap, it's seriously fast.
By design NX will remain king for certain applications in this department, but this advantage is quickly disappearing for the exact same reasons that work in favour of Wayland (newer apps rely on toolkits rather than the old and crufty X11 APIs)

(sorry for hijacking the thread)

How old is this project? Why doesn't it get more attention? etc

Posted Feb 14, 2012 19:23 UTC (Tue) by dlang (guest, #313) [Link]

I don't see an update or two a month as being a big problem for blurbs to LWN

and it sure would help visibility of the project.

How old is this project? Why doesn't it get more attention? etc

Posted Feb 17, 2012 21:32 UTC (Fri) by wookey (guest, #5501) [Link] (1 responses)

wow, screen for X, and I knew nothing about it. Absolutely no need to apologise for 'thread hijacking'. This is a very useful thing indeed, which apprently not enough people know about. I've waited for NX for many years but it's always been a big pain in practice (forks, licencing, server not in Debian). Anything that gives me reconnectable-at-home/work X apps is _extremely_ useful. X over ssh is OK, but it doesn't give you the 'reconnect' feature.

If it's good it might even get me out of a range of terminal-based core practices which are text-based because the 'reconnectable single instance' aspect is the most important thing (irc, email).

How old is this project? Why doesn't it get more attention? etc

Posted Feb 17, 2012 23:38 UTC (Fri) by khc (guest, #45209) [Link]

I've been using winswitch (http://winswitch.org/) which wraps around Xpra and gives you a pretty GUI to work with.

NX dead end?

Posted Feb 14, 2012 13:44 UTC (Tue) by mjthayer (guest, #39183) [Link]

> In one shot you solve one of my biggest problems (long story...) and I only find out because I happened to read all the *comments* on a story?

Quite often I find that comments on LWN are as valuable as the stories themselves. (Which are excellent of course.)

Xpra

Posted Feb 14, 2012 15:03 UTC (Tue) by bawjaws (guest, #56952) [Link] (1 responses)

Is the 'xpra' available from the Ubuntu repositories your fork or the original. If the original do you have a link detailing the differences?

Xpra

Posted Feb 14, 2012 17:49 UTC (Tue) by amtota (guest, #4012) [Link]

Ubuntu ships the old version, Debian testing has it though so maybe Precise Pangolin will ship it? (Debian is already quite a few versions behind, but it will sync again)
As for the list of changes, they are listed right on the home page: http://xpra.org/

NX dead end?

Posted Feb 18, 2012 12:19 UTC (Sat) by Jonno (guest, #49613) [Link]

Please note that xpra is a "VNC-like protocol" (eg it sends images, not render commands, over the network), and represents pretty much exactly what you eventually can expect to get from Wayland.

It is even implemented in the same general way as remote Wayland are intended to eventually be implemented, eg. it is a "compositing window manager" that don't actually composes the windows but sends them over the network instead.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 22:23 UTC (Mon) by elanthis (guest, #6227) [Link] (16 responses)

That is not the common answer. You are one of the many who keep misinterpreting the (probably poorly phrased) answer: a VNC-like remote display protocol is better than an X11-like remote drawing command protocol. That means that a remoting protocol that focuses solely on the upload of (compressed) image buffers is better than a remoting protocol that focuses on sending rendering commands to the server. It does NOT mean that VNC's many other undesirable qualities are meant to be kept in any future Wayland remoting system.

X11 was designed in the day when apps just draw lines and solid rectangles and used server-side fonts. Here in 2012, apps have smooth gradients and rounded corners rendered with complex series of Cairo compositing commands and interesting effects rendering with intricate GL uses that require lots of buffer uploads and feedback. X11's design no longer reflects how applications are written.

VNC is not at all an ideal protocol to use. All the Wayland folks are saying is that the idea of uploading image buffers (like VNC) will be the future. Things like how VNC's image buffers are crappily compressed or how VNC must export an entire desktop rather than individual windows is not something anybody wants to keep around. Hence, VNC itself is not the answer. People mentioning VNC are talking ONLY about the broad general idea of sending image buffers.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 1:09 UTC (Tue) by nix (subscriber, #2304) [Link] (6 responses)

It seems to me that an ideal protocol would upload images to the remote end only when the local application informs the local server of them (capped at most once per display refresh). Sending images on every single display refresh, even if you already sent the same image in the last refresh, is pointlessly inefficient. That's what VNC does, and that is all that's wrong with remote display protocols as compared to remote command protocols.

i.e., do with the remote protocol what Xft and GlyphSets did for client-side fonts.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 2:59 UTC (Tue) by aliguori (subscriber, #30636) [Link] (5 responses)

VNC only sends updates (1) to the dirty region of the framebuffer (2) at the request of the client.

As it turns out, in real life, the framebuffer changes constantly so the use of a refresh rate for something like VNC is to batch updates. But only dirty portions of the screen change.

Where VNC lacks compared to modern remote display protocols is things like offscreen image buffers and z-ordering.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:19 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

The framebuffer changes constantly, but when textual output is being displayed it normally changes to display the same bits of stuff over and over again (or the same bits of stuff over and over again, alpha-composited onto a constant background or a constant background pixmap). If the remoting model used by VNC represented this properly, it would be very low-bandwidth indeed. I hope the remoting model used by Wayland, when it eventually gets one, can do the same.

(Yeah, this won't handle the hard cases where people are playing any game, at least any game by Jeff Minter, or where people are displaying text in dancing fonts atop animated shaded backgrounds, but text display is a lot of what X, or any windowing system, is *for*. Forget xterms -- think IRC clients or web browsers displaying any textual article. GlyphSets *rule* for bandwidth reduction: no content-unaware compression algorithm could get remotely the same size reduction for the same low CPU use. Discarding that would be terrible.

Given that the inventor of GlyphSets is involved in Wayland I suspect that it will not be forgotten.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:53 UTC (Tue) by aliguori (subscriber, #30636) [Link] (2 responses)

>The framebuffer changes constantly, but when textual output is being displayed it normally changes to display the same bits of stuff over and over again (or the same bits of stuff over and over again, alpha-composited onto a constant background or a constant background pixmap). If the remoting model used by VNC represented this properly, it would be very low-bandwidth indeed.

It doesn't. All modern tool kits do their own font rendering (this is what Pango provides).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:59 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Yeah. They do their own font rendering, rendering to glyphs which are then sent to X as a GlyphSet, right?

Wayland - Beyond X (The H)

Posted Feb 16, 2012 0:05 UTC (Thu) by aliguori (subscriber, #30636) [Link]

Oh, I was not aware of the GlyphSets extension. VNC only has a very simple bitmap based protocol that can provide updates to the bitmap at a rectangle granularity.

It has no concept of offscreen bitmaps, alpha blending, or anything like that.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:40 UTC (Tue) by Cato (guest, #7643) [Link]

There is a way to do offscreen image buffers with VNC, though it's a bit of a hack. You x11vnc's client-side caching feature, which allocates a huge long screen buffer, and tell the client that the screen is less tall than it appears. See http://en.wikipedia.org/wiki/X11vnc#Client-side_caching

X11VNC lets you VNC to the main X screen as well, while SSVNC is a handy Linux client that does the tunnelling for you.

I find that UltraVNC on Windows works fine as a client to x11vnc, and TightVNC viewer on Linux is OK too.

iSSH on iPhone almost works but is currently rather crashy for VNC. If anyone else can recommend solid VNC-over-SSH clients for iOS I'd really like to know them.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 2:28 UTC (Tue) by wahern (subscriber, #37304) [Link] (1 responses)

You can't do rendering and compositing for dozens or hundreds of applications all on the same machine. The implication is that Wayland doesn't see a future for thin clients. Or perhaps that the future of thin clients will be HTML.

Perhaps someone should start an X server implementation for HTML5 using JavaScript, WebSockets, Canvas, etc.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 4:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>You can't do rendering and compositing for dozens or hundreds of applications all on the same machine.

But you can! A decent 3D graphics card can handle many many many windows just fine. You'll be limited by the network bandwidth, RAM or CPU long before you hit 3D card's limits.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 8:14 UTC (Tue) by amtota (guest, #4012) [Link]

> VNC must export an entire desktop rather than individual windows

Try http://xpra.org/ instead.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 8:31 UTC (Tue) by jch (guest, #51929) [Link] (2 responses)

> a VNC-like remote display protocol is better than an X11-like remote drawing command protocol

Note that there's more to remote X than just rendering -- X is pretty good at event distribution (the mouse pointer is only tracked when the client cares about the mouse pointer position) and avoidance of race conditions (the passive grab mechanism).

The latter is an absolute must over laggy links -- it is what allows opening a menu and choosing a menu entry *before* the menu entry appears. The former is probably helpful on asymmetric links (ADSL lines etc.).

--jch

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:22 UTC (Tue) by mgedmin (guest, #34497) [Link] (1 responses)

OTOH it's not fun if the network connection stalls when a remote app has a server grab. You can't do _anything_ with your machine (except maybe Ctrl+Alt+F1).

Wayland - Beyond X (The H)

Posted Feb 15, 2012 15:40 UTC (Wed) by nix (subscriber, #2304) [Link]

What we really need is an automatic server-side timeout for grabs. If you take an input device grab and don't release it fast enough, you lose the grab and get sent an event about it (older apps can't deal with that event, but often can recover anyway in my experience, maybe taking a click or two to realize that this menu should be closed really). If you take a full server grab and don't release it fast enough, your X connection is dropped and the grab is released.

('Fast enough' is a difficult question, particularly for mouse grabs which are often held for fairly long periods. A customizable interface is probably best, perhaps something like a minute for keyboard and mouse grabs by default and a second for full-blown server grabs. Clients can opt out of this behaviour, but if any do and are not screensavers they can expect much mockery.)

Would this work, or am I babbling insanity?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 8:44 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

Yes, the current situation is a bit silly: if you run a GTK+ or Qt application over the network you're mostly sending rendered images over the wire, hardly making use of X's remote drawing primitives. (Which is a pity in some ways, I kind of liked the old X11 server-side bitmap fonts, but they don't really fit into the modern internationalized, Truetypey world.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:47 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

That's wrong. You send a GlyphSet once, then after that you just tell the server to 'composite that Glyph I sent you earlier from that GlyphSet *here*'.

Without this remote textual display programs (not just xterms: IRC clients, emacs, you name it) would never be able to scroll at tolerable speed.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 14:28 UTC (Tue) by epa (subscriber, #39769) [Link]

Thanks for the correction.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 21:58 UTC (Mon) by tstover (guest, #56283) [Link] (63 responses)

Wayland might actually help the situation. All of the ideas that conflict with the network transparent X11 model might be able to flourish in the wayland world. Ideas regarding the evolution of X then could then continue to support network transparency with less debate.

Currently Wayland can run inside X, and eventually X inside Wayland.

I'm sure there will be some great things to come from a fresh start.

X is mature, healthy, and will be around for a long long time. Something as CRITICAL and WIDELY DEPLOYED as X over the network is not going to disappear just because an alternative focused on faster local rendering materializes.

...and Yes I am typing this in a web browser - and that browser most certainly IS running on a remote LAN host with ssh X11 forwarding. :)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 2:31 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (2 responses)

>Currently Wayland can run inside X, and eventually X inside Wayland.

But, what about Wayland inside X inside Wayland?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 2:58 UTC (Tue) by Kit (guest, #55925) [Link] (1 responses)

Actually, Xorg already works inside Wayland, both rootless and fullscreen. The Wayland screenshots (http://wayland.freedesktop.org/screenshots.html) of X running inside Wayland are actually taken from inside a (at least I presume) X session... so you have Xorg on Wayland on Xorg!

Wayland - Beyond X (The H)

Posted Feb 14, 2012 8:55 UTC (Tue) by iksaif (guest, #54284) [Link]

Some screens of X inside Wayland inside X: http://xf.iksaif.net/dev/wayland/
native Xorg [ Qt Wayland compositor [ xwayland + x clients ] ]

Wayland - Beyond X (The H)

Posted Feb 14, 2012 8:19 UTC (Tue) by khim (subscriber, #9252) [Link] (59 responses)

Something as CRITICAL and WIDELY DEPLOYED as X over the network is not going to disappear just because an alternative focused on faster local rendering materializes.

You may show of the X over network as much as you want but the simple fact: people don't use it. The biggest hint is the fact that the most common usecase from Windows world (I work late in the evening, decide to continue from home via remote access) does not use X at all. It uses NX or some other kludge, but not X. Was it possible to extend X to support this usecase? Probably - but noone cared. This means that world is already split in two: people who use X networking continue to use it and preach it's usability, while "new generation" does not care at all. Similar to the situation with network filesystem in 1990th (when Netware calmed that something as CRITICAL and WIDELY just can not disappear).

I doubt X will disappear completely: old version or it and old versions of program (X-compatible, not Wayland-compatible) will always be available. But at some point new programs will stop using it and will stop supporting it.

Natural progression of life: either you adopt or you disappear. And X networking refuses to adopt.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:25 UTC (Tue) by pboddie (guest, #50784) [Link] (1 responses)

Huh? I can't be the only person to use X over SSH, even if I don't do it as often as I might (and certainly, VNC or xpra would be better for certain programs that "need" a GUI but also run for long periods).

And you mean "adapt" not "adopt".

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:34 UTC (Tue) by lally (guest, #71211) [Link]

I did, but don't anymore. I use SSH for remote login, emacs/tramp for text editing, and a local web browser for our company apps. I suspect that a lot of original uses for remotely-accessing graphical apps are reduced with the prevalence of webapps.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:46 UTC (Tue) by nix (subscriber, #2304) [Link] (36 responses)

You may show of the X over network as much as you want but the simple fact: people don't use it.

You keep saying this even though people keep popping up in response to your words and saying 'I use it' over and over again. Since you're ignoring people directly telling you that your assertion is wrong, yet you keep making it, why should we believe anythign else you have to say?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 19:56 UTC (Tue) by khim (subscriber, #9252) [Link] (35 responses)

You keep saying this even though people keep popping up in response to your words and saying 'I use it' over and over again.

Yup. The very same group of few dozens of people raise huge racket again and again.

Since you're ignoring people directly telling you that your assertion is wrong, yet you keep making it, why should we believe anythign else you have to say?

It's your choice. Either you are creating desktop for the masses (and that means 'I use it' arguments are sent straight to /dev/null where they belong), you you continue to "scratch your own itch" till it's raw.

Long, long ago people who wrote the software were more-or-less the same as people who used said software. Back them it made sense to ask your users and do as they say. Today not only developers are different from users, what's worse majority of user are not presented on the forums where developer participate.

Thus you need to use indirect methods. For example you can count number of Macs (which don't support anything besides VNC) and PC laptops (which at least theoretically can support network transparency) on Linux conferences.

This number clearly grows - and that means that people are not bothered by lack of network transparency. For the applications which are designed to be run over network you can continue to use X - it's quite compatible with Wayland.

But for applications designed to be run locally network transparency is just useless abstraction.

I already wrote about this "you don't exist" phenomenon before.

The fact is: most users value "pretty pixels" way, way, WAY above network transparency. I wrote about this, too.

You may think that "serious feature" should not ever be sacrificed for "useless embellishments", but in reality it's the other way around. If your application is ugly then nobody will want it and if your platform encourages creation of ugly applications then your platform will be ignored by Joe Average completely.

The last example which shows that is surprising: it's Micrsoft's WP7. It was designed with very simple, streamlined, fast interface in mind. And people like that. The problem Microsoft faces: without enough blitz in the interface people will not even try to use it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:29 UTC (Tue) by dlang (guest, #313) [Link]

so you are saying that you don't care that people are using this feature, they aren't enough people to matter, so if they can't use your new windowing system, tough luck.

and you wonder why people get upset at pushing this new windowing software as the future of computing.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:26 UTC (Tue) by jonabbey (guest, #2736) [Link] (2 responses)

'Thus you need to use indirect methods. For example you can count number of Macs (which don't support anything besides VNC) and PC laptops (which at least theoretically can support network transparency) on Linux conferences.'

That's odd, both of my Mac laptops support X11.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:41 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

I think the conversation has now passed some sort of event horizon. Macs support X11 in the same fashion Wayland does

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:45 UTC (Tue) by jonabbey (guest, #2736) [Link]

Yeah, I realized after I posted that he was speaking more of remote accessibility for native Quartz apps and that my counter was a bit off target.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:20 UTC (Wed) by daglwn (guest, #65432) [Link] (4 responses)

> and that means 'I use it' arguments are sent straight to /dev/null where
> they belong

Sums up perfectly the disgust people have at the attitude of the Wayland community.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:40 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

:"Sums up perfectly the disgust people have at the attitude of the Wayland community."

How so? None of the wayland developers have posted here. khim doesn't represent the wayland community any more than you do.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 4:38 UTC (Wed) by daglwn (guest, #65432) [Link] (2 responses)

Somebody better tell him to pipe down, then, because he's giving them a bad reputation.

Given the quotes in the article, I don't know that he's far off from the developers.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 16:30 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Regardless of what you might think of khim's opinions, I don't believe he is giving them a bad reputation at all unless you blame Wayland developers for his opinions which you have no reason to do at all. If you want to know their opinions, ask them

Wayland - Beyond X (The H)

Posted Feb 17, 2012 2:30 UTC (Fri) by jschrod (subscriber, #1646) [Link]

khim *is* giving them a bad reputation.

If they don't want that, maybe, they should start to get involved in the discussion on one of the important, if not the most important, Linux news sites? Life's a bitch and all that...

Wayland - Beyond X (The H)

Posted Feb 15, 2012 18:57 UTC (Wed) by jedidiah (guest, #20319) [Link] (22 responses)

> Yup. The very same group of few dozens of people raise huge racket again and again.

It's not 1990 anymore. The concept of X over the network is no longer as strange as you would like to pretend. The inclusion of a bad implementation of this idea in MacOS is ample demonstration of this. The network GUI concept is fairly commonplace in the corporate Windows world. If anything, people should be improving these features in Linux rather than trying to abandon them.

If the Wayland crowd have their way we will have a perverse situation where Windows is better at rendering it's GUI across the network than Linux is.

MacOS+VNC is just plain painful and is nothing that should be held up as an example of how Wayland might work.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 19:04 UTC (Wed) by khim (subscriber, #9252) [Link] (20 responses)

MacOS+VNC is just plain painful and is nothing that should be held up as an example of how Wayland might work.

Right. But there are undeniable fact: Mac is the only platform which significantly grown market share over last 10 years or so (Windows is losing it, Linux is stagnating).

Everyone agree that MacOS+VNC combo had nothing to do with that: people hates this side of MacOS. But apparently butter-smooth MacOS experience is highly relevant to said growth - and it's direct consequence is this exact MacOS+VNC combo.

Thus I'm not sure I want to demand network transparency (as many here are doing): sure, it's nice feature to have, but if lack of network transparency will be compensated by great local experience it still can be a net win as MacOS shows.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 19:37 UTC (Wed) by jedidiah (guest, #20319) [Link] (19 responses)

The "butter smooth" MacOS experience is mostly mindless hype. It completely evaporates once your requirements are non-trivial.

Want a Mac? Buy yourself a Mac. Don't sabotage Linux.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 20:12 UTC (Wed) by tstover (guest, #56283) [Link] (18 responses)

Indeed.

The growth of OSX is directly related to non-technical customers being forced to find alternatives to windows over the course of its continued odyssey into free-style mass self destruction. To even suggest otherwise requires completely entering into an alternative reality. Most end users don't want to pay an extra 500% for a computer.

This also echoes the rise of Linux for that matter in the 90s with technical users.

(the ipod/itunes societal downfall is an orthogonal issue)

Wayland - Beyond X (The H)

Posted Feb 15, 2012 21:52 UTC (Wed) by khim (subscriber, #9252) [Link] (17 responses)

The growth of OSX is directly related to non-technical customers being forced to find alternatives to windows over the course of its continued odyssey into free-style mass self destruction. To even suggest otherwise requires completely entering into an alternative reality.

And how we've entered realm of pure fantasy and self-delusion.

To even suggest otherwise requires completely entering into an alternative reality.

Perhaps. But then it just means that we all were moved to this alternate reality recently. When you participated last in some developer's conference? Number of Macs dwarfs number of Linux laptops on events like GDC. And not just among PHP developers. Googlers also overwhelmingly prefer them over Linux laptops. And that's in a company which uses Linux almost exclusively on servers and which officially gives supported Linux laptops for the ones who prefer them! If Google engineers are mindless non-technical customers then who are these mythical highly techinical customers who prefer the "X-based Desktop Linux" mess?

This also echoes the rise of Linux for that matter in the 90s with technical users.

Sadly 90th have come and gone. Now it's Windows for non-technical users and MacOS for the users who want actually usable *nix.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 23:29 UTC (Wed) by tstover (guest, #56283) [Link] (15 responses)

Non-technical user does not mean "mindless". A brain surgeon and a rocket scientist may simply want to browse the web when they get home from work, and potentially not also being heavily involved in "I.T." would therefore still be described as a non-technical user.

Guess that was a little too baited and off topic. It's just that I had to sit through another ipad consumerism drool session earlier today, and for some "crazy" reason thought there still might be someone left on LWN that would at least understand.

I'll concede that mac laptops are everywhere. Yes I see them outnumbering Linux ones at events (which I do go to), and yes the iron curtain of osx is now the apparatus of conformity and fashion that windows once was.

My comments were on how this came to be, not so much why it perpetuates.

I will say though, that you should at least open yourself to the possibility that maybe, just maybe - PHP, game, and google developers do not constitute the core of "linux users". Or for that matter that most people would even think of osx as a *nix. (although it is).

Regarding the mythical users, I'll put it like this. Everyday some kid somewhere discovering computing for the first time is hooked. That first program written, or that first system built, or that first network turned on, or that first cloud image deployed, or what ever it is they do now - is all it took. For the rest of their lives, that is all they will ever want to do. No one will ever dissuade them, lock them out, or shut them down. They can not walk away even if they wanted to. Whether or not F/OSS was involved in this pivotal moment, eventually it to enters into their bloodstream, and that to becomes a force far too powerful to walk away from. Given time, the thought of relinquishing the power of say Linux for a proprietary death sentence like osx, would be like a free man bowing down to a king.

How many of them are there? No one knows. We lurk in your schools and businesses. We hand out information and software to anyone who wants it. At air ports we see the sea of apple hardware, and actually desire not to be just like everyone else. At conferences we even show people how and why to overwrite the "X-based Desktop Linux mess" right on top of their windows and osx factory software, so that they too might also be free some day.

For what it's worth I've never said I was anti-wayland. My first post was stating that I think is going to help X development.

I'm really not even anti-osx. If we were in person, I would light up a cigar and open a bear with you, because if your actually reading my comments then you probably are either as bored or as distracted as I am.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 9:14 UTC (Thu) by khim (subscriber, #9252) [Link] (14 responses)

I will say though, that you should at least open yourself to the possibility that maybe, just maybe - PHP, game, and google developers do not constitute the core of "linux users".

No? WTH NO? These are the people who write and run software on Linux five days per week. Very few of them develop anything for MacOS. Yet they overwhelmingly prefer to use Mac to develop said Linux software. Don't it say you something about current state of affairs? Note that few years ago they all had iPhones, today a lot of them use Androids - and not just Googlers (where it's obvious choice because most of them get Androids as a gift from Google), but people on the other side of the fence, too. This means that Apple does not have a monopoly on good design and Linux (the kernel) is not the culprit. But something else is for such things don't happen without a reason.

How many of them are there? No one knows. We lurk in your schools and businesses. We hand out information and software to anyone who wants it. At air ports we see the sea of apple hardware, and actually desire not to be just like everyone else. At conferences we even show people how and why to overwrite the "X-based Desktop Linux mess" right on top of their windows and osx factory software, so that they too might also be free some day.

Well, that's good explanation of where Linux developers come from, not where Linux users come from. And while developers are always valuable it's the lack of users which is problematic. Till you have certain amount of users hardware companies ignore you, they don't publish specs and don't explain how to use the goodies - thus you spend your limited developer's resources trying to reconcile changes in "latest and greatest" hardware (made without Linux in mind because there are so few users) with your software, it's often broken, etc.

Linux on server obviously is big enough to keep hardware companies interested while Linux on desktop is not. And as FreeBSD example shows server may not be to keep given OS alive and thriving.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 14:52 UTC (Thu) by tstover (guest, #56283) [Link] (13 responses)

-Anyone developing on a laptop full time is due for some serious hand, neck, and back injuries. (this is not flame bate, but a very serious warning from experience of many)

-Android != Linux

-knowing a bunch a people who work at google that use mac laptops + using one yourself != no one uses X11 linux computers

-developing "for linux" on mac, either means one is running linux in a vm, remoted into linux, or is doing cross platform development. For instance I do cross platform development for *nix, windows, and yes osx. I still hate osx, and only put up with on the last stages of compiling and testing. I also hate windows, which is why I, like zillions of others use, - wait for it - linux computers.

-Sure apple and google are popular and having their days in the sun. Look beyond the main stream in all aspects of life, and you will find so much more. Seek individuality, beauty, nonconformity, nature, books, the human being, and you will find these things do not come from advertisements, top 40, and expensive fashion electronics.

-One thing I do like about wayland is trying to simplify the programming model. Reminds of of SDL with the concept of frame buffers in windows.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 18:06 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

>-Anyone developing on a laptop full time is due for some serious hand, neck, and back injuries. (this is not flame bate, but a very serious warning from experience of many)

I've been doing it for more than 10 years. You can put a laptop on a table, you know.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 19:24 UTC (Thu) by tstover (guest, #56283) [Link] (11 responses)

give it about another 6 years. Somewhere around year 17-18 is when I was forced to address the situation.

Sure just like "everything else" the con artists, lawyers etc, are out there with some just stupid comments, but that doesn't mean there isn't a real danger.

Of course this has much to do with how tall you are, how big your hands are, etc. Also most of the hand problems are actually do to unknowingly bending ones wrists while sleeping. Research has found people who type allot or play guitar for instance often start to do that. Eyes are another area to start taking care of.

Sure a quick session here and there is fine, but if your are going to sit down for the day its another story.

When I put one on a table, I put something under it to keep my neck from having to bend down, and use an external keyboard & mouse (preferably kinesis advantage and kensington trackball)

Leaning forward hunched over in the "oger position" will drop you for sure, given enough time. The blood flow in your neck being pinched off also exponentially increases your chances of a stroke.

These are not irrecoverable injuries though. It was actually the best thing that ever happened to me. After chiropractor + physical therapy, diet and exorcise put the lifestyle induced diabetes back in the closet. I've never been healthier.

No B.S. I tell these younger folks all the time about these things. If this is your career and you plan be able to do this for decades, then you really need to take care of your body. Stop eating the poisons, and get some real exorcise. Never underestimate how closely related your physical and mental health are either.

So in conclusion, X11 network transparency is a feature I like.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 20:23 UTC (Thu) by khim (subscriber, #9252) [Link] (9 responses)

Leaning forward hunched over in the "oger position" will drop you for sure, given enough time.

This is kind of strange, because people who needed to read a lot used lecterns for centuries - and if you open your laptop case to about 130-140° you basically get the same thing on about optimal distance from eyes. It's not as if human body is designed to only ever see the sky, you know.

I think the problems with laptops starts when people try to uncritically apply rules designed for desktops (screen is vertical, top of the viewing screen at eye level, etc). But laptop's screen is way below you! If you'll constantly bend your body in the position to put your eyes at the level with the top of the screen I'll be surprised if you'll manage even few years! Good keyboard is harder to find but this is where YMMV significantly: some people have trouble even with good ergonomic keyboards, some can live with laptops just fine. I, for one, find ThinkPad's keyboard easier to deal with then traditional Keyboard+Mouse combo - because I don't need to move hands to use mouse: trackpoint is right in the middle of keyboard, after all (if I need precision then mouse is obviously better, I'm talking about web surfing, text editing, etc).

Wayland - Beyond X (The H)

Posted Feb 16, 2012 20:31 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

you can get full size keyboards with a trackpoint (or with a touchpad below the spacebar, almost as good)

Wayland - Beyond X (The H)

Posted Feb 16, 2012 20:46 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

you can get full size keyboards with a trackpoint

There are very few of them and they are no better then ThinkPad's built-in one, so what's the point?

or with a touchpad below the spacebar, almost as good

Not even close. Either you need to use thumb to move mouse pointer (way less precise then when you use index finger) or you need to move hands (and if I'll do that then I'll prefer traditional mouse over touchpad becase, again, it's more precise).

Wayland - Beyond X (The H)

Posted Feb 16, 2012 21:23 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

> There are very few of them and they are no better then ThinkPad's built-in one, so what's the point?

the rest of the keyboard is much better

Wayland - Beyond X (The H)

Posted Feb 16, 2012 21:53 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

the rest of the keyboard is much better

How come? Most of the look like this - basically laptop keyboard without a laptop. Not exactly sure how separation of keyboard from laptop can suddenly make it "much better".

Wayland - Beyond X (The H)

Posted Feb 16, 2012 22:45 UTC (Thu) by dlang (guest, #313) [Link]

two things.

1. having it be separate lets you position it better.

2. I was actually assuming that you would get a 'real' keyboard. In the past I've seen full-size M series type 'clicky' keyboards that have the erasermouse pointer in them.

by the way, I somewhat question if a thumb on a trackpad is really that much less accurate than the erasermouse joysticks, but I guess that's a personal preference :-)

Wayland - Beyond X (The H)

Posted Feb 16, 2012 20:43 UTC (Thu) by tstover (guest, #56283) [Link] (3 responses)

Using a lectern one is either standing, which has totally different muscle usage in the back (and you wouldn't do it all day), or has it closer to eye level than a laptop on a table. Reading is still a problem for me. Usually I have to sit a table to prop up my elbows and hold the book higher up. I'm an extreme case though. Sometimes certain car wreck injuries create the same problems for people. hunched over computer use leads to condition known as "upper cross syndrome", which can sometime be seen in swimmers and certain weight lifting patters. It's awful.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 20:52 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

Using a lectern one is either standing, which has totally different muscle usage in the back (and you wouldn't do it all day), or has it closer to eye level than a laptop on a table. Reading is still a problem for me.

This may be the key difference. I have 20/20 vision (rarity today, I know) thus text on latop in aforementioned position is just perfect for me.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 21:08 UTC (Thu) by tstover (guest, #56283) [Link]

> This may be the key difference. I have 20/20 vision (rarity today, I know)

as do I. (up until a few years ago it was even better than that). For many the issue is very much leaning forward to get closer to the screen. One of the many reasons I recommend monitor arms for desktop systems.

Torso height is the other big factor. If you sit with proper posture without bending your neck and your eyes can look close to straight ahead - then great! Many people have to sharply look down to do this which is unnatural to say the least. This causes the had to bend down, which eventually caused the back to slouch.

If you are reading this and you find your self doing this, please take the chance to start new habits.

Wayland - Beyond X (The H)

Posted Feb 22, 2012 7:39 UTC (Wed) by ssmith32 (subscriber, #72404) [Link]

I have a few co-workers that have their desks set up so they can stand up and work. I get the impression it's not so bad once you get used to it. Sort of like sleeping on a hard floor. It seems weird for a while, but doing that for a year or so improved some lower back issues I had quite a bit. People can stand for hours idling their time away on electronics... haven't you seen the lines at Apple stores :D ?

Wayland - Beyond X (The H)

Posted Feb 23, 2012 18:57 UTC (Thu) by sdalley (subscriber, #18550) [Link]

tstover, thank you for your very sensible comments about posture.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 21:02 UTC (Thu) by cdmiller (guest, #2813) [Link]

This statement:

"and MacOS for the users who want actually usable *nix."

appears to fall under:

"And how we've entered realm of pure fantasy and self-delusion."

Wayland - Beyond X (The H)

Posted Feb 15, 2012 23:22 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> It's not 1990 anymore. The concept of X over the network is no longer as strange as you would like to pretend. The inclusion of a bad implementation of this idea in MacOS is ample demonstration of this. The network GUI concept is fairly commonplace in the corporate Windows world. If anything, people should be improving these features in Linux rather than trying to abandon them.
Nobody is trying to abandon anything. The X.org server will still run on Wayland, and if application or toolkit developers choose to abandon support for X11, you should blame them and not the Wayland developers. OTOH, Wayland is what finally gives us a chance to invent a new remote rendering protocol that, unlike X11, doesn't suck for modern applications.

Wayland - Beyond X (The H)

Posted Feb 19, 2012 5:44 UTC (Sun) by AngryChris (guest, #74783) [Link] (2 responses)

You lost me here:

" For example you can count number of Macs (which don't support anything besides VNC) and PC laptops (which at least theoretically can support network transparency) on Linux conferences."

cbell@athena:~$ ls -ld /Applications/Utilities/X11.app
drwxr-xr-x 3 root wheel 102 Jan 13 00:23 /Applications/Utilities/X11.app
cbell@athena:~$ uname -a
Darwin athena.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
cbell@athena:~$

I use X11 on my Mac all the time. I never use VNC.

Wayland - Beyond X (The H)

Posted Feb 19, 2012 6:39 UTC (Sun) by raven667 (subscriber, #5198) [Link] (1 responses)

What you are describing is the same state as wayland currently. You can display remote MacOS apps via VNC and you can display and remote X11 apps but the native display protocol is not X11 and the X server is not where the graphics drivers live.

Wayland - Beyond X (The H)

Posted Feb 20, 2012 12:41 UTC (Mon) by dgm (subscriber, #49227) [Link]

Exactly. You will be able to run X11 on top of Wayland, the same way you can get it on OS X or even Windows.

The X11 protocol will still be used, but basically for where it really makes sense: applications running remotely on another host. Local applications will work better (less round trips, less display artifacts, less processes and contexts switches involved) on Wayland.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:46 UTC (Tue) by Cato (guest, #7643) [Link] (2 responses)

I have actually tried X11 from Windows PCs to Linux - it was quite painful to get working, and extremely slow even on a 100 Mbps LAN - I know that's an implementation issue as it worked fine in the old days on 10 Mbps LANs but it shows that remote X11 isn't very useful for Windows to Linux remote access.

VNC and NX have both worked well, though setting up an NX server looked too painful to contemplate.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 14:04 UTC (Tue) by tstover (guest, #56283) [Link]

I do that almost every day. It's been working wonderful for years. Putty + xmingw or cygwin on most hardware of the last 5 - 7 years on 100 or 1000mpb ethernet is very very close to a local application. Multiple remote computers, text editors, browsers, gimp sessions, many users, all day M-F. No I'm not making this up. In fact it's even mixed in with the similar 'doz feature from 2008r2.

Sure this sucked back with nt3.5 + exceed + 10mbp or what ever...

and on my home LAN with linux on both sides it's also great. although I use local browsers and media players.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 7:49 UTC (Wed) by ronnyadsetts (subscriber, #47268) [Link]

> I have actually tried X11 from Windows PCs to Linux - it was quite painful
> to get working, and extremely slow even on a 100 Mbps LAN - I know that's
> an implementation issue as it worked fine in the old days on 10 Mbps LANs
> but it shows that remote X11 isn't very useful for Windows to Linux
> remote access.

Running X remotely with ADSL connections both ends and speed is more than acceptable. That's ~1.8Mb/s upstream at one end and 800Kb/s upstream at the other end.

It's certainly much better to use than VNC over the same connection, both speed wise and graphical quality wise.

I suggest that something is wrong with your set up if the speed is unacceptable over 100Mb/s.

Losing network transparency for X to me would be losing one of it's biggest strengths.

Ronny

Wayland - Beyond X (The H)

Posted Feb 14, 2012 15:08 UTC (Tue) by daglwn (guest, #65432) [Link] (16 responses)

> You may show of the X over network as much as you want but the simple
> fact: people don't use it.

I use it. There are use cases that require it, including every machine accessed through a remote terminal.

Why do Wayland supporters keep insisting no one cares about remoting when lots of people say otherwise?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 16:55 UTC (Tue) by drag (guest, #31333) [Link] (15 responses)

> Why do Wayland supporters keep insisting no one cares about remoting when lots of people say otherwise?

Why do Wayland bashers continue to ignore the obvious fact that Wayland will be perfectly capable of support X11 Networking?

There is the fear, of course, that developers may stop using X11 and use Wayland native thus you lose the ability to do X11.

The counter argument is easy:

Of course, if developers and users see value in X11 they will continue to use it and insist for it's support. So as long as people have value in it it will exist.

It is worth noting that your choices are not limited to just X11 or VNC...

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:20 UTC (Tue) by daglwn (guest, #65432) [Link] (14 responses)

> Why do Wayland bashers continue to ignore the obvious fact that Wayland
> will be perfectly capable of support X11 Networking?

No, it won't. It will be able to run an X server as a client. That's not the same thing.

> There is the fear, of course, that developers may stop using X11 and use
> Wayland native thus you lose the ability to do X11.

Bingo.

> Of course, if developers and users see value in X11 they will continue
> to use it and insist for it's support.

The whole point of Wayland is to get rid of X, isn't it? If not, then what is the point? I'm not opposed to dumping X, but the replacement has to be fully functional and that includes network transparency.

> It is worth noting that your choices are not limited to just X11 or
> VNC...

Every alternative I've tried to remote X performs worse. I don't think my situation is unique.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:59 UTC (Tue) by raven667 (subscriber, #5198) [Link] (5 responses)

> The whole point of Wayland is to get rid of X, isn't it? If not, then what is the point?

If I read the Wayland docs correctly the point is to simplify local graphics handling by providing direct access to the toolkits, X11 will be a major client application to this graphics stack for the foreseeable future. This is not about removing the X11 protocol its about not requiring the X protocol server to also drive the graphics display, separating X protocol handling from driving graphics cards.

> Every alternative I've tried to remote X performs worse. I don't think my situation is unique.

That seems odd because raw X11, even tunneled over a compressed SSH session, is the worst performer of the available protocols (except maybe for uncompressed VNC). RDP and ICA to a Windows system is significantly better, NX (and apparently xpra which I haven't personally used) makes a big difference for X and there are other protocols such as SPICE and the VMware one which are also better, in pretty much every way. Many of these protocols can even do individual window redirection and not just full desktop remoting.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:48 UTC (Tue) by daglwn (guest, #65432) [Link]

All of those alternatives also require running some kind of networking process on the remote machine. I don't have to do that to use ssh -X. I don't have admin privileges on most application servers and the sysadmins tend to get testy if I install local servers.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:15 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

Why do people keep saying RDP is any good? It's dire. I've used it over both limited-bandwidth and high-latency networks, and the number of whole-framebuffer repaints it does when only a few characters have changed is beyond a joke. It's usable -- just. I don't really think 'usable -- just' is a good target to aim for.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 9:21 UTC (Wed) by Fowl (subscriber, #65667) [Link] (1 responses)

I'd be interested in your experience.

The only time I've seen full repaints are with less aware toolkits, eg. Swing. Chrome's content area frame is opaque to the remoting stack too and is treated as a bitmap because of the way that they've done their buffer management/sandboxing.

(Assuming both the client and server were running NT 5+ clients - if there's enough of a feature missmatch then RDP will fallback to a vnc-like scheme, which isn't very good because it's not often used.)

Also, Citrix and other 3rd parties have made enhancements that some people may not distinguish from vanilla rdp.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 15:36 UTC (Wed) by nix (subscriber, #2304) [Link]

I've seen it on Windows->Windows connections with Swing, VNC (sigh), XWin, and even MS Office 2008-or-whatever-number-it-is at the other end. Not every repaint is a full repaint: they seem to happen almost at random.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 19:02 UTC (Wed) by jedidiah (guest, #20319) [Link]

RDP is not bad when you consider the alternatives.

It certainly beats anything that's being proposed by anyone pushing Wayland.

Short of X itself, all of the alternatives to RDP are even more dire.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 19:41 UTC (Tue) by drag (guest, #31333) [Link] (7 responses)

> No, it won't. It will be able to run an X server as a client. That's not the same thing.

It will be able to connect and display X clients. That's X11 networking.
Why is it such a surprise that it's going to run a program to provide X functionality?

It's like saying you can't browse the web with Wayland because you need to use a web browser.

> The whole point of Wayland is to get rid of X, isn't it?

No.

The whole point of Wayland is to provide a modern and relatively easy to platform for writing graphical programs. It will provide the ability for application developers to use direct rendering for their applications using whatever method or API is best suited for the application or the audience.

This is something that is not possible with XFree DDX we use today and X11 is one of those methods that application developers can choose to use.

It only intends to get rid of the need of XServer running you hardware. You can still have your XServer.

Saying that Wayland is intended to get rid of X11 is like saying that Wayland intends to do away with HTTP.

> If not, then what is the point? I'm not opposed to dumping X, but the replacement has to be fully functional and that includes network transparency.

Ok?

Trying to putting it into perspective:

I have 'network transparency' with Windows 7. I don't know why people that is X11 is so special or so required if you want to use remote applications.

It's not the only game in town and it's been a VERY VERY long time since it was even a good one. The world has moved on. The reason is that we still have relatively high latency links. We have lots of bandwidth that is plenty for running remote applications, however latency have not dropped by the same amount. Latency is what kicks X11's ass and is something that X11 is very poor at dealing with. All of which means that X11 is not suitable solution for what most people use remote apps for... which is things like implementing VDI and accessing applications over the internet over high latency links.

Keep in mind a _A_LOT_ of people use remote apps. My dad uses remote apps. 90% of people at my work use remote apps. Teachers, students, accountants.. all sorts of people use networking for remote GUI apps. They just don't use Linux, nor do they use X11 to do it.

Maybe X12 will make it useful once again. But keep in mind that it's going to be a lot easier to implement X12 support on top of Wayland then it's going to be with Xfree. This is because you can easily keep your backward compatibility with a X11 server integrated in Wayland while vastly reducing the overhead needed to implement a X12 server...

Wayland - Beyond X (The H)

Posted Feb 14, 2012 19:45 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

>> No, it won't. It will be able to run an X server as a client. That's not the same thing.

> It will be able to connect and display X clients. That's X11 networking.
Why is it such a surprise that it's going to run a program to provide X functionality?

make it possible to run a Wayland app and display it on an X display and you have what people need.

Then we can talk about the efficiency and performance of the Wayland remote capability. If all it does is shove full-resolution screenshots to the X display, it's not going to work very well.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:19 UTC (Tue) by nix (subscriber, #2304) [Link]

make it possible to run a Wayland app and display it on an X display

That's not that important. What matters is two things, really:

- That an X11 client for Wayland exists such that a Wayland server can display remote (and local) X apps. This seems overwhelmingly likely to be written or the transition process would be impossible. (It also seems likely that such a client would be transparently-started and per-window, making X apps look indistinguishable from native Wayland apps).

- That something exists such that remote Wayland clients can be displayed on local Wayland servers with reasonable efficiency (comparable to or better than current X, not giant bitmap-hurling horrors like VNC). So far I have received a mass of conflicting opinions regarding whether this is desirable or even possible. If this is implemented as a bunch of toolkit-level hacks, then I very much hope that no applications ever come to support Wayland except via those toolkits, because Wayland apps that only work locally will break the illusion that all machines are one machine that I very much value. (X is surprisingly good at this. I've watched full-motion 1680x1050 video over X connections on gigabit ethernet and it's worked so well that I didn't notice that I was running remotely until the video ended. It falls over in a heap if SSH tunnels are involved, of course -- SSH just can't transfer that much information that fast, nor was it ever designed to.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:06 UTC (Tue) by khim (subscriber, #9252) [Link] (4 responses)

It's even worse:

The reason is that we still have relatively high latency links. We have lots of bandwidth that is plenty for running remote applications, however latency have not dropped by the same amount.

Yup. Exactly. What's worse: in the future situation will go from bad to worse, the to the worst.

Imagine how the state of the art XXV century technology will look like. Bandwidth will probably be astronomical. Enough to shove 7680×4320 frames 120 times per second and more. Latency... Worst-time latency will still be 67ms on average, 133ms worst case. Calculations are trivial: 20000km-40000km round-trip (average 20000km, worst case 40000km), 300000km/sec, you do the math.

Why people still are trying to invent stupid schemes to reduce bandwidth requirements by adding more round-trips is beyond me: these schemes will be useless pretty soon, why try to add them to the new protocol?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:05 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, unless we get FTL :) Those guys with neutrinos are clearly up to something.

But yeah, light-speed lag is going to the limiting factor for a long time.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:26 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Worst-time latency will still be 67ms on average, 133ms worst case

Hah. I wish. I use X (a bit, it is too slow to be useful most of the time) from my parents' house, in the wilderness, a whole ten miles from a major tourist spot in Yorkshire, so obviously the back of beyond (that's millions of centimetres, nobody could hope to string a cable that far). Satellite link to geosynch and back, then down to Italy, then back to England. 660ms RTT. This is the only broadband they are likely to get for at least the next twenty years. And they are relatively lucky: at least they didn't have a hill stopping them from seeing geosynch. What people in the Scottish highlands are doing for connectivity I have no idea, but it is probably not pleasant.

I don't expect any remote display protocol to cope with that sort of latency.

Why people still are trying to invent stupid schemes to reduce bandwidth requirements by adding more round-trips is beyond me: these schemes will be useless pretty soon, why try to add them to the new protocol?

Who on eath is trying to do that? Reducing round-trips has been core to X protocol optimization since the start: anyone trying to increase them (excepting only perhaps do-only-once stuff which is amortized to zero) is a nutter. However, not even local network bandwidth is yet free, and with 10GbE equipment at the cost it is now ($4000 for a basic switch!) I'd expect a long long wait before that becomes common enough that we can consider that it is even ten times cheaper than it is now.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:42 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>I don't expect any remote display protocol to cope with that sort of latency.

But RDP can do this, it'll be uncomfortable but usable. I had to use RDP a couple of times on congested GPRS/EDGE links with similar latencies.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 19:02 UTC (Wed) by alankila (guest, #47141) [Link]

We should seriously study if we could just radiate information on tight beam straight through the Earth, presumably through some kind of fixed networking stations. Might get that worst-case latency down to 12000 km light time (40 ms). At least some particles are going to pass through Earth; difficulty may lie in both generating them headed to the right direction, and with detecting them...

Wayland - Beyond X (The H)

Posted Feb 14, 2012 4:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (58 responses)

It's already possible to run a rootless X inside Wayland.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 4:26 UTC (Tue) by dlang (guest, #313) [Link] (57 responses)

Yes, but if programmers shift to using a Wayland based library instead of an X based library it won't do you any good to be able to run X inside Wayland.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 6:34 UTC (Tue) by raven667 (subscriber, #5198) [Link] (56 responses)

Is an assertion that is not backed up by any facts that I am aware of. Do you think the major toolkits will rip out X11 support the day Weyland hits 1.0 in some sort of mass suicide pact? x11 will still be supported for cross platform applications for the foreseeable future. It takes a great galloping leap of logic to assume otherwise.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 7:44 UTC (Tue) by dlang (guest, #313) [Link] (47 responses)

I wouldn't expect a major, cross platform library to ditch X11 support

but unless there's a library that works with Wayland and is perceived to be better than X11, what's the point of creating Wayland?

and I would not expect a library created for Wayland to include support to run on X11 as well. first off it would add significant complexity to the library (probably undermining the performance on Wayland), but also any support that does exist is probably not going to be well tested, after all the people selecting that library are selecting it because they want to use Wayland.

In addition, there are a lot of people claiming very publicly that cross platform compatibility is holding back development of Linux (I don't just mean LP with systemd and journald, or GNOME talking about needing to be their own OS, not just a layer on top of Linux, but these are some of the biggest examples)

So why would I expect that cross platform compatibility is going to be so high on everyone's priority list?

Statements about how features haven't been used by anyone for a decade when people are using them daily don't reassure me either, for some strange reason ;-)

and this completely ignores any possibility of a ditry trying to create some tools that would be hard for other distros to use without jumping ship and making Wayland their display manager as well.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 10:23 UTC (Tue) by farnz (subscriber, #17727) [Link] (46 responses)

The point of Wayland is that even if all the Wayland clients are rootless X servers, merging input handling into the compositor is a net gain. It means that whatever transformation is applied to the output can also be applied to the input seamlessly.

And maybe that's where we'll end up; native Wayland is used for the compositor, and all the applications are X11 based, running on rootless X servers.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:16 UTC (Tue) by rqosa (subscriber, #24136) [Link] (45 responses)

> merging input handling into the compositor is a net gain

But X11 doesn't inherently require a separate window manager / compostiting manager. For example, MacOS X's rootless X server (and similar ones, such as Exceed for Windows) will use the native window system's window borders if there is no X window manager running. So, there's no reason in principle why there can't be an X server for Linux that has its own built-in compositing window manager.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:49 UTC (Tue) by raven667 (subscriber, #5198) [Link] (44 responses)

I imagine that this idea was considered and was found to be too horrible to entertain.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:51 UTC (Tue) by rqosa (subscriber, #24136) [Link] (43 responses)

Care to explain what's wrong with it? The way I see it, in the local-applications-only use case, an X server with built-in compositing together with a widget toolkit capable of direct rendering (DRI2 and OpenGL ES and/or OpenVG) would give all the features that Wayland is supposed to have, while being a less disruptive change.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 19:17 UTC (Tue) by raven667 (subscriber, #5198) [Link] (26 responses)

Well for one that would be a major architectural change for the x.org server that might not be appreciated by all the consumers of it (and certainly not by competitive compositors/window managers). Which compositing window manager would you make the x.org server standard? That's the horrible part. It also is more complicated, if the apps are going to direct render with DRI2, then what benefit is there to running everything through the X server rather than treating the X server as just another direct render client. The Wayland approach is architecturally more simple and robust.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:37 UTC (Tue) by rqosa (subscriber, #24136) [Link] (25 responses)

> Well for one that would be a major architectural change for the x.org server that might not be appreciated by all the consumers of it (and certainly not by competitive compositors/window managers).

But Wayland is also a major architectural change that requires existing compositing window managers to adapt to it. (If I understand correctly, it requires existing compositing window managers to be rewritten as servers that talk the Wayland protocol.)

> Which compositing window manager would you make the x.org server standard? That's the horrible part.

Then Wayland is equally "horrible" (because it combines a compositing window manager and a display server into a single application, just like what I'm suggesting).

if the apps are going to direct render with DRI2, then what benefit is there to running everything through the X server

"Everything" doesn't run through the X server — that's what "direct rendering" means. But we still need a server for input handling and window management. And the extension system in the X protocol allows for (local-only) direct-rendering clients (DRI2 + EGL or GLX) to coexist with (remote or local) indirect-rendering clients (XRender or AIGLX), with possibly even the exact same applications able to run in either direct or indirect mode. (For example, an OpenGL application can run on either GLX+DRI2 or AIGLX. Maybe an accelerated-indirect version of EGL would give good enough performance for running OpenVG applications remotely?)

> The Wayland approach is architecturally more simple and robust.

How is it more simple? If you're "treating the X server as just another direct render client", then you still need to have an X server present, and you also need for input events to pass through two servers (rather than one) before reaching the client. And if you're using only direct-rendering clients, you could have a minimal X server that omits extensions you're not using (e.g. XRender). (And even if you don't omit them, it seems like the only cost would be some more memory pages allocated to the X server, which would then get paged out because they're not actually being used.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:48 UTC (Tue) by raven667 (subscriber, #5198) [Link] (2 responses)

Wayland is a new component and isn't going to require architectural changes to the x.org server to support. Compositing window managers will need to be ported to Wayland, and one is being developed alongside for reference but that one isn't mandated or baked in so there can still be competitive window managers. I think that is where the confusion is, if I understand the architecture correctly, the compositing window manager is still a replaceable component.

Wayland is being designed and implemented by the same people who designed and implemented DRI2, AIGLX and X11 itself so I think they probably know more than I do about what is the most sane architecture to implement. As you describe, if you have a minimal X server that is only handling direct rendering clients, then you have Wayland. Call it X12 in your head if you like.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:31 UTC (Tue) by rqosa (subscriber, #24136) [Link] (1 responses)

> if I understand the architecture correctly, the compositing window manager is still a replaceable component.

If by "replaceable component" you mean a separate process, then no, it isn't. See this blog posting by the developer of Compiz:

Unlike X11 where we have a bunch of clients push to a display server, and then an external window manager / compositing manager process, in wayland we have a single process for a display server and compositing manager. There is no window manager, all of that is pushed to the clients (move, resize, etc).

My understanding is that there is a library ("libwayland") which implements the server side of the Wayland protocol, and compositing managers (such as Compiz, KWin, etc.) are supposed to be rewritten as daemons that talk the Wayland protocol to clients (with the actual server implementation being in libwayland, which they link to — I'm guessing that the program is supposed to register several event-handler callbacks with libwayland, then call into a main-loop function that libwayland provides, and the provided callbacks will be called in response to things like input events and start/stop of client programs).

It just seems to me that, in principle, it should be possible to adapt the X.Org Server so that it becomes just like this — a shared library to be embedded by compositing manager programs (or alternately, have the the X server remain a daemon but add a plugin API to it that allows for compositing managers to be developed as in-process plugins to the X server).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:46 UTC (Tue) by farnz (subscriber, #17727) [Link]

In principle, you could indeed rewrite the existing X server to provide a suitable interface to plug a compositor in, much like Wayland. But if you look at the X.org codebase, you realise that it's a complete mess, despite all the cleanup work that's been done, and that this is a harder task than the way round that Wayland has done it (where X becomes just another client of a Wayland system).

The people doing this aren't complete idiots - they're the people who are keeping X11 going today. They're hitting the pain points of the current codebase, and Wayland began as an experiment to see if they could do something useful with the parts they already have, without a long silent period where they're simply refactoring all the cruft out of the existing X server codebase. Turns out, the answer's yes - it could just as easily have been "no, not interesting unless you refactor X.org".

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:52 UTC (Tue) by wmf (guest, #33791) [Link] (2 responses)

> But Wayland is also a major architectural change that requires existing compositing window managers to adapt to it. (If I understand correctly, it requires existing compositing window managers to be rewritten as servers that talk the Wayland protocol.)

Actually, I think people expect existing compositors to die and everyone will just use Weston. Although we may see Weston-Unity and Weston-GNOME forks.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:06 UTC (Tue) by raven667 (subscriber, #5198) [Link]

Yeah, that's what I would expect, GNOME and KDE to have their own forks or to implement Wayland directly in kwin and Mutter, similar to the evolution of compiz.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:30 UTC (Tue) by tjc (guest, #137) [Link]

> Although we may see Weston-Unity and Weston-GNOME forks.

And certainly Weston-Cinnamon. :)

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:17 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (18 responses)

Have you _seen_ the X codebase?

It's ancient. It has all kinds of arcane features (like an x86 real mode emulator for legacy BIOS drivers!!!). Moving compositor inside Xorg would require huge refactoring of a giant codebase which only a handful of people on Earth really understand completely.

Wayland on the other hand is small and concise. You can easily write a Wayland protocol implementation in a _weekend_ (spoiler: I have a pure Java implementation).

Adapting existing frameworks for Wayland is also not terribly hard. QT, GTK and EFL already have alpha-quality implementations which covers the majority of currently used frameworks.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:56 UTC (Wed) by rqosa (subscriber, #24136) [Link] (5 responses)

> It has all kinds of arcane features (like an x86 real mode emulator for legacy BIOS drivers!!!).

Who cares? Any system that's capable of running Wayland (which requires Linux and KMS) doesn't use that part of X.Org anyway.

> QT, GTK and EFL already have alpha-quality implementations which covers the majority of currently used frameworks.

That's the problem, right there. We wouldn't be complaining if Wayland were just a piece of infrastructure for the X server to use — but if the toolkits are going to migrate to the native Wayland protocol, then we lose the ability to use all of our current remoting solutions (NX and xpra) other than VNC (or potentially some future slightly-improved variation of VNC, which still will have bad performance compared to things like RDP).

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:00 UTC (Wed) by rqosa (subscriber, #24136) [Link]

s/running Wayland/running the existant Wayland compositing servers/

Wayland - Beyond X (The H)

Posted Feb 15, 2012 15:52 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

Quite so. Awesome local performance is great -- I don't want to argue against it. But gaining awesome local performance (which, for most apps I use, is moving things from too-fast-to-see to too-fast-to-see) at the cost of *all* remote performance (moving things from slight-delay to oh-now-I-can't-do-my-work-at-all) is a very definite loss.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 10:42 UTC (Thu) by intgr (subscriber, #39733) [Link] (2 responses)

> moving things from too-fast-to-see to too-fast-to-see

Well, not in my experience. I can sense a noticeable delay in most GUI applications. Click on a menu and it takes some time for the dropdown to appear. Click on a button and it takes noticeable time for the next window to pop up.

I'm consistently amazed when I see my coworkers using their well-maintained Windows XP machines. It's as if menus pop up before they're actually clicked. Simpler applications start up with no visible delay.

Maybe some of my problem is the fact that I use weak-ish graphics cards in a dual monitor configuration. Maybe it's suboptimal drivers. Maybe it's inefficient GUI toolkits. Maybe it's power management. But sure as hell, my X11 desktop has crappy interactivity.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 23:13 UTC (Thu) by rqosa (subscriber, #24136) [Link] (1 responses)

Windows XP might feel more responsive because it doesn't use compositing, which can have a performance cost (especially on older GPUs). On my 4.5-years-old hardware, programs feel slightly more responsive when KWin's compositing is turned off than when it's on.

(And of course there's also the possibility that the slowness you're experiencing is the fault of the applications and/or the widget toolkits, rather than the underlying window system. For example, I've noticed that Qt4 seems a lot slower than Qt3 when running on older CPUs.)

Wayland - Beyond X (The H)

Posted Mar 1, 2012 14:01 UTC (Thu) by nix (subscriber, #2304) [Link]

Quite. I'm still using KDE3 (well, Trinity). Too-fast-to-see. I can't see what compositing brings to the table other than wobbly windows, which I really don't care about.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 15:51 UTC (Wed) by nix (subscriber, #2304) [Link] (11 responses)

The x86 real mode emulator is there to handle userspace modesetting for cards for which initialization requires the execution of x86 BIOS code without requiring the machine to be an x86 (or to allow it to happen while the x86 is in long mode), and which don't have enough information provided in another form (e.g. as tables) to permit reliable initialization in any other way. Among other things this includes all pre-ATOMBIOS Radeon cards, so this piece of ugly is not going away until userspace modesetting does.

If Wayland is going to drop that, it's dropping UMS as well (which is quite plausible).

Wayland - Beyond X (The H)

Posted Feb 15, 2012 16:02 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

Wayland have never used UMS (and I don't think it ever would), it relies on KMS.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 18:37 UTC (Wed) by dlang (guest, #313) [Link] (9 responses)

well, if you were to take the X codebase and drop every driver that doesn't use KMS, and then further limit your target platform to Linux (the only OS with KMS), there is a HUGE amount of code that you could drop.

but as long as you want to provide _any_ output on these other systems, you need to have all this 'cruft' in the codebase.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 21:10 UTC (Wed) by khim (subscriber, #9252) [Link] (8 responses)

but as long as you want to provide _any_ output on these other systems, you need to have all this 'cruft' in the codebase.

Well, the logical conclusion says that there will be no Wayland support for these systems. Not a big loss.

P.S. You can as well complain that Wayland will not support X terminals.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 6:34 UTC (Thu) by jmorris42 (guest, #2203) [Link] (7 responses)

> Not a big loss.

Uh huh. So no cross platform, no network transparency and mixing mechanism and policy. Fail, fail and fail. Not seeing any Win to balance it so Meh. Sure Lennart Pottering isn't involved in this project? Seems to have the same trademark militant rejection of every single philosophical underpining that made UNIX/X/GNU a winner.

And notice how all three are under active attack, Pottering is hammering away at the core assumptions of UNIX, Wayland is directly aimed at the key product differentiators that made X a legend and we are suddenly seeing concentrated attacks on GNU and the GPL. Hmmm.. If you can't beat em straight up, make a long march through thier institutions and gut em from within? I guess the endpoint pf all this is a GNOME 4 written in Mono, locked to local display on Wayland and licensed under BSD. Bah.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 9:38 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

Sure Lennart Pottering isn't involved in this project?

Nope. Net yet, anyway.

Seems to have the same trademark militant rejection of every single philosophical underpining that made UNIX/X/GNU a winner.

s/winner/looser/

UNIX/X/GNU already lost the workstations, desktops, tablet and mobile. What's left? Ah, server… Care to explain where exactly X11 is a big win on server? AFAICS server Linux thrives in spite of X11, not because of X11.

I guess the endpoint pf all this is a GNOME 4 written in Mono, locked to local display on Wayland and licensed under BSD.

Well, if this will finally make the platform usable for normal people then it still will be a win.

So no cross platform, no network transparency and mixing mechanism and policy. Fail, fail and fail. Not seeing any Win to balance it so Meh.

The win is supposedly simpler and more robust codebase which will make it possible to write snappier, more fluid interfaces. If the promise will be fulfilled then the whole exercise will be justified, otherwise Wayland will be just an article in a Wikipedia.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 12:12 UTC (Thu) by rqosa (subscriber, #24136) [Link] (2 responses)

> s/winner/looser/

It's not a "loser" for the many people who are using it right now.

> Well, if this will finally make the platform usable for normal people then it still will be a win.

If making it usable for some hypothetical "normal people" means making it unusable for the current users, that's not a win.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 14:49 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

If making it usable for some hypothetical "normal people" means making it unusable for the current users, that's not a win.

It's free software. Current users can use current version of the stack or even create a fork - it's to them.

If Wayland will lose few existing users and gain a lot new users it will still be a net win. Yes, it's a gamble, but it's well-considered gamble.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 9:38 UTC (Fri) by alankila (guest, #47141) [Link]

To co-opt certain language that's been popular recently, Linux currently is for the 1 %, not the 99 %. You can afford to lose some of that 1 % if you gain nearly any fraction of the 99 %: number of users would increase dramatically.

And as you correctly observed earlier, traditional Linux's biggest problem right now is that it does not have enough users, and that is an existential threat because it means no games, no hardware support, and eventually not even computers to run it on. We probably need customer demand for Linux to even have a long-term future. This problem must be fixed, and we're going to need kick-ass local graphics among other things. I'm sure that we can do better than X network transparency also, because it's at least possible when we finally start to seriously look into doing it at toolkit level.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 14:01 UTC (Thu) by michich (guest, #17902) [Link]

> So no cross platform, no network transparency and mixing mechanism and policy. [...] Sure Lennart Pottering isn't involved in this project?

Do you realize that the guy gave you workable network transparency for audio?

Wayland - Beyond X (The H)

Posted Feb 16, 2012 18:02 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>I guess the endpoint pf all this is a GNOME 4 written in Mono, locked to local display on Wayland and licensed under BSD. Bah.

You are describing Android. And yeah, it's a win - it's the most popular OS for end-users right now.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 22:47 UTC (Thu) by rqosa (subscriber, #24136) [Link]

But those users already have an operating system they like (one that is already FLOSS, even). So how can there be there any good reason to change GNOME (and the underlying infrastructure it uses) to make it more like Android?

(And if your answer is something like "Android isn't really FLOSS", then the real solution to that is that we need to have unlocked hardware capable of running the community-developed Android rebuilds like CyanogenMod and Replicant on, and to educate the public about why locked-down hardware is bad.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:12 UTC (Tue) by farnz (subscriber, #17727) [Link] (15 responses)

That's basically what X on Wayland is - another way to look at Wayland is that it's the construction kit to build such an X server, and as we're putting all the bits together, we might as well expose the lower layers so that you can bypass X if you want to.

Wayland's protocol is a spiritual subset of X11 - it's basically clipboard data exchange, input and DRI2, without the rest of the X11 bits. The trouble with building this atop X11 is that the interactions between X11 core protocol and the subset that Wayland provides are nasty (for example, X11 has traditional input events that "know" that you only ever have one mouse position and a set of buttons - what is the "correct" mouse position if you're doing multitouch input? Where did you touch when you make the "zoom in" gesture - the start point? The end point? - noting that "neither" and "both" aren't acceptable answers to core X input), and you have to get them right to truly claim to be "an X server with built-in compositing". The rules around subwindows are another example

Wayland takes it in a different direction - throw away the bits that are hard to implement yet rarely used, and make a Wayland client (the X server) implement them if they're wanted. If network transparency really is a critical feature, someone will step up to implement it - whether by doing the work themselves, or by paying someone such as Red Hat to include it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:24 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

I understand that X supports multiple mice on a screen, and I've seen stuff recently about it supporting multitouch as well.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:11 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

It has some deep seated issues around the way multiple mice and multitouch interact with "traditional" X clients - if we could just assume that all X applications will be rewritten to assume multitouch support, we could get rid of a decent collection of interesting special cases.

There are at least three cases that XI2 just can't get right when interacting with traditional X clients:

When I have multiple simultaneous touch points, where is the "correct" location for the emulated single touch? There's no right answer for this - it could be one or more of the individual touch points, or it could be the position of the cursor, or it could be an average of the locations of the touch points. Exactly which one is right is a function of the underlying UI, which X can't see into.
If the user does a "global" gesture, you need to tell the client "I know I've been feeding you motion and touch events, but actually, they've turned out to be a global gesture. You need to forget that they happened". The alternative is to not send the events at all until touch up - painful if you're trying to drag an icon.
With multiple input devices, how do I synthesise the single mouse that a traditional X client expects? Whatever I do is going to fail in some corner cases - either there will be button events that don't correspond to your expectations (e.g. because I simply serialised two mice worth of events into one stream, and mouse one was trying to drag an icon when mouse 2 came in and double-clicked a different icon), or there will be a lack of events when you expected some (e.g. because mouse 1 is lurking over a window, but you've moved mouse 2 over it as well, and have forgotten about mouse 1).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:38 UTC (Tue) by khc (guest, #45209) [Link] (1 responses)

Curious comment from a bystander, how does wayland plan to address these issues? Specifically 1) and 2).

Wayland - Beyond X (The H)

Posted Feb 15, 2012 12:15 UTC (Wed) by farnz (subscriber, #17727) [Link]

Wayland's way of addressing them is simple - it doesn't have a historic protocol to worry about, so it can assume that you are multitouch aware. It handles them the same way XI2 does when dealing with XI2 clients.

Specifically addressing the three points I made earlier:

When you have multiple touch points, Wayland reports all the touch points individually, including their locations, and the client is expected to work out what that means. For example, it could highlight a button if any of the touch points are within that button, if that's appropriate for this client.
Touch event streams are terminated with either a "touch complete - go process" or "actually, that was the beginning of a global gesture - ignore it" event. This lets applications provide feedback to the user as the touch happens (e.g. drag pointer instead of normal pointer), but delay taking action until the touch completes.
You get events from each input device individually, so the client can distinguish event streams from multiple mice.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 10:36 UTC (Wed) by renox (guest, #23785) [Link] (8 responses)

> Wayland's protocol is a spiritual subset of X11

The issue is at which point a subset is good enough?

> If network transparency really is a critical feature, someone will step up to implement it

Which network transparency?
Inefficient network transparency based on buffer would be easy to add sure, but efficient network transparency to Wayland would need to change a lot Wayland, adding the equivalent of XRender in the API (especially the part used for text rendering) so that toolkits would need to be significantly changed also (may not be too difficult actually for a multi-platform toolkit which can also use X11, but for a Wayland-only toolkit..).

Wayland - Beyond X (The H)

Posted Feb 15, 2012 12:25 UTC (Wed) by farnz (subscriber, #17727) [Link] (7 responses)

So, the expected path is that Wayland handles local compositing and input. There will probably be a VNC-alike inefficient remoting protocol for native Wayland at some point, assuming anyone gets interested (which is a safe assumption, as VNC exists for platforms like Windows that didn't have a native remoting protocol from day 1).

Something else, toolkit specific since that's the layer at which you have semantic information to do a good job, will handle efficient network transparency. You can already do this today for GTK+ by writing a new GDK backend that produces a network stream that can be fed back into GDK at the other end.

And note that (because Wayland's protocol is basically a subset of X11's) it's entirely possible already to produce an X11 toolkit that cannot be efficiently transported over the network. I've already encountered proprietary X11 applications whose custom toolkits handle X11 by sending repeated full-window bitmaps over the wire, after all, so it's not like X11 is a guarantee that you'll do something network-efficient.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 13:54 UTC (Wed) by renox (guest, #23785) [Link] (5 responses)

> Something else, toolkit specific since that's the layer at which you have semantic information to do a good job

Toolkits have the information yes, but hopefully they can use a generic protocol (say Wayland 2.0 with something like Render added), not a toolkit specific protocol: it would be a compatiblity nightmare..

Wayland - Beyond X (The H)

Posted Feb 15, 2012 15:29 UTC (Wed) by farnz (subscriber, #17727) [Link] (4 responses)

The problem right now is that we don't actually know what that generic protocol should look like. XRender is better than core X11, but is still neither good enough for modern toolkits (which are moving to OpenGL to escape the problems with XRender), nor as efficient as something like NeWS was.

Hopefully (yes, I'm an optimist), we will see some experimentation with remoting protocols as a fallout from Wayland, and eventually find a better compromise than "accept the limitations of X11".

Wayland - Beyond X (The H)

Posted Feb 16, 2012 13:08 UTC (Thu) by renox (guest, #23785) [Link] (3 responses)

> XRender is better than core X11, but is still neither good enough for modern toolkits (which are moving to OpenGL to escape the problems with XRender)
Which issue are you talking about? The speed of the rendering?
I expect that any protocol which is network efficient (WAN) will reduce the rendering speed, it's a tradeoff..

> nor as efficient as something like NeWS was.
Sure, but I don't think that it's possible to keep current toolkits and have them implement something like NeWS or Fresco/Berlin.

But current toolkits already support X11 so if there was a Wayland2.0 which was (Wayland1.0 + the useful parts of X11 to have network (WAN) access), then it should be possible to have the toolkits use this..

Wayland - Beyond X (The H)

Posted Feb 16, 2012 13:41 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

XRender is rather limited in functionality, as compared to OpenGL (only considering the 2D rendering case here). As a result, you end up rendering parts of the toolkit as bitmaps (which you ship over the wire as-is when running networks), when a better API like OpenGL lets you offload work to hardware. Toolkit authors want to produce prettier toolkits than XRender can support (see Clutter for an example of a toolkit that makes use of OpenGL features that just can't be efficiently rendered via XRender).

If they're happy with X11's protocol, they're unlikely to go to the effort of porting to Wayland - why bother coding a completely new backend, when your existing X11 backend will already work with Wayland? Equally, why limit yourself to systems running Wayland if you can work with any systems that run X11?

Note that Wayland is still a success if all it does is act as the construction kit for X11 systems that integrate window management, input handling, and compositing. It doesn't need all the clients to talk native Wayland to have succeeded.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 17:18 UTC (Thu) by renox (guest, #23785) [Link] (1 responses)

> XRender is rather limited in functionality, as compared to OpenGL
Yes but:
1) OpenGL is a moving target
2) You cannot simply send OpenGL commands from the client to the server otherwise any command to allocate something would create a round trip.
So you'd have to have a smart proxy on the client, goto (1).
3) With some luck, OpenGL commands to read pixels from buffers would not be an issue as they're already slow, so they're unlikely to be used.

> If they're happy with X11's protocol, they're unlikely to go to the effort of porting to Wayland

I don't understand your remark: there is work to port GTK and Qt to Wayland, clearly some developers want the faster local rendering that Wayland should provide..

The question is about the remote rendering backend: should the X11 backend be kept forever? Can it be improved for WAN access(*)?
Or is-it possible to replace it with something even better for WAN on top of Wayland?

*:After all, in the long run (if Wayland is ported to other Unix), this should be its main purpose.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 18:42 UTC (Thu) by farnz (subscriber, #17727) [Link]

While OpenGL is a moving target, it is a standard, and what's on offer is extended, not reduced. You can choose a useful subset, available on all interesting platforms, and just use that, while still getting more than XRender offers you. Given that people are moving toolkits to OpenGL, there's clearly a demand for more than XRender offers from the perspective of toolkit authors.

Explaining my remark in more depth; nothing in the Wayland world stops people sticking to X11 indefinitely. If Wayland + XRender (or Wayland + OpenGL 1.4 - the upper limit of indirect GLX) is Good Enough, toolkit authors are unlikely to expend the effort to port to Wayland for no net gain. Given that the only gain from Wayland is to permit you to drop legacy code related to the network-transparent subset of X11, the only sensible reason for toolkits to port over and stop caring about X11 is that they want to do things that they can't do network-transparently in X, either.

Therefore, should toolkits stop bothering to maintain a network-transparent X11 backend, it will be because they're doing things that they couldn't do in network-transparent X11. The benefit of Wayland here is that they have to explicitly decide that "not network transparent" is acceptable - they can't simply be an X11 application that does not work over the network due to DRI2 dependencies.

Thus, the toolkits have to make a decision about remote rendering; is it an irrelevance to their users? Is X11 good enough (in which case they will maintain an X11 backend)? Is there a better way (in which case they will implement it, and possibly kill off Wayland in the process)?

Wayland - Beyond X (The H)

Posted Feb 15, 2012 15:55 UTC (Wed) by nix (subscriber, #2304) [Link]

When you think about it, this is mostly what we have today. Most of what core X does (drawing lines, arcs, rendering fonts and the like) is stuff which would these days go into a toolkit. Obviously the point at which this semantic information is available is the point at which network-transparency should be implemented. If you implement it by throwing huge bitmaps around -- whether in a Wayland compositor, or in present-day X handling current Pango-and-Gtk apps over a network -- you're going to get lousy performance.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 19:10 UTC (Wed) by jedidiah (guest, #20319) [Link] (1 responses)

I suppose you could consider Wayland as a way to rebuild Xorg from the ground up but that's not the way it's being presented. It primarily seems to be a rallying point for X haters. The point really seems to be to abandon X entirely. Lip service given to features missing in Wayland just seem to be an attempt to deflect justifiable criticism.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 9:57 UTC (Fri) by alankila (guest, #47141) [Link]

The ultimate problem here is that getting good local and remote network performance simultaneously is very hard. And we currently sacrifice great deal of local performance through having a middle-management layer such as X, or protocols like GLX, or AIGLX, or whatever.

The idea that clients have direct access to GPU and can render directly with it, and everything else is told to get out of the way will allow superb local performance, but at the cost of removing X-style network transparency because there is no component other than the client and the GPU that even knows what is being rendered. So the ways to get network transparency are:

1) request GPU for textures, try to compress them and send them;
2) use toolkit which actually has the semantic knowledge of what is being displayed and can use some intelligent interface to represent the gui data.

Hence the perfectly reasonable request that toolkits should do the network transparency, because they have the semantic information to actually do a good job.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 10:06 UTC (Tue) by renox (guest, #23785) [Link] (7 responses)

[Do you think the major toolkits will rip out X11 support the day Wayland hits 1.0 in some sort of mass suicide pact?]

Remember that a lot of the toolkit maintenance is made by the desktop projects, which are not especially famous for their backward compatibility..

So it's quite probable that very soon after Wayland is usable (not 1.0 obviously), they'll say use VNC instead of X/FreeNX if you need remote access, we don't support X anymore. It sucks on WAN? Well we don't care.

After all, if developers really cared about remote (WAN) access, FreeNX would have been integrated in the X project one way or the other.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 13:43 UTC (Tue) by nye (subscriber, #51576) [Link] (2 responses)

>After all, if developers really cared about remote (WAN) access, FreeNX would have been integrated in the X project one way or the other.

I'm curious about this: when I tried FreeNX (it was a couple of years ago; maybe that's important) I found it to be *far* worse than x11vnc, which is *just barely* usable over ADSL. X over ssh of course was worlds away from usable - many seconds for minor display updates for example.

Are other people finding FreeNX to be significantly better than x11vnc?

(And of course, they're all atrocious compared to RDP to a Windows machine)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 16:49 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

> Are other people finding FreeNX to be significantly better than x11vnc?

Yes. Very much so.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 12:11 UTC (Wed) by nye (subscriber, #51576) [Link]

>> Are other people finding FreeNX to be significantly better than x11vnc?

> Yes. Very much so.

Sorry to keep pestering - I'm trying to work out what might be the differences in situations which would explain why people in this thread have such wildly varying experiences:

Do you know in what kind of environment NX shines compared to x11vnc?
I'm mostly thinking of normal, consumer-level ADSL links, so RTT of 50-150ms (where 50ms is on a good day with no load, and 150 is about the worst you're likely to see until bufferbloat kicks in), uplink speed of around 256kbps (768 if you're really lucky), extreme bufferbloat (so RTT can occasionally go up into the seconds if the connection is loaded beyond 90% or so).

In that scenario you have to use so much compression with VNC that it looks awful because the screen's covered with JPEG artefacts, but it's good enough for occasional remote administration at least. RDP to Windows has similarly tolerable performance while looking fine, and both X and FreeNX have been completely unusable for me.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 19:52 UTC (Wed) by jedidiah (guest, #20319) [Link] (3 responses)

Wayland itself is already a "mass suicide pact". If the Wayland developers and proponents are quick to leave us out in the cold then the toolkit developers can do the same. It only requires that the toolkit maintainers have the same disregard for the end users that the Wayland developers do.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 20:01 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

The arguments that "nobody needs that" from the Wayland people sound very similar to the arguments made by the GNOME people. I could easily see GNOME adopting a Wayland-only approach.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 20:35 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

You are again making the mistake of confusing random posters and the position of Wayland developers. "nobody needs that" hasn't been uttered by any Wayland developer.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 23:34 UTC (Wed) by HelloWorld (guest, #56129) [Link]

The arguments that "nobody needs that" from the Wayland people

When did any Wayland developer ever say anything like that?

I use network transparency

Posted Feb 14, 2012 22:07 UTC (Tue) by david.a.wheeler (subscriber, #72896) [Link]

I do run GUI programs remotely, using X (and ssh). So I do depend on network transparency. I'm sure I'm not unique, either.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 21:48 UTC (Mon) by am (subscriber, #69042) [Link]

The article talks about this on page 3:

> Høgsberg's response to this problem has said that although Wayland isn't a remote rendering API, it already works by being informed of changes to client buffers through events and that the compositor could then send the new pixels in that region out over the network. He adds that "the Wayland protocol is already violently asynchronous, so it should be able to handle a bit of network lag gracefully", which suggests that while network transparency isn't high on the priority list, it could be implemented on Wayland without a fuss.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 22:15 UTC (Mon) by elanthis (guest, #6227) [Link] (83 responses)

Sigh. The other responses are the usual "I have no idea what the hell I'm talking about" crap that always comes up with Wayland discussions. Let me spell it out quickly.

First, the network transparency of X in today's environment is not ideal. The original X protocol is designed around server-side rendering. That doesn't happen anymore in today's apps. Almost all rendering apps on the client, and so even in networked X environments, the client is just sending big image buffers across the network. Only X's protocol sucks pretty hard at doing this. Additionally, X's protocol requires a lot of roundtrips, so it suffers from bad latency on congested networks. Lastly, even the advanced server-side rendering built into things like GLX is mostly useless today due to a combination of GLX not being kept reasonably up to date and again the need for applications to frequently and quickly upload large buffers to the GL server (hard to keep fast enough even on the local machine; impossible to keep fast enough over a network).

Second, there are other networked protocols that are much much better for today's networks and today's applications. These protocol have a minimum number of round trips and focus on the client application uploading buffers to the server. These protocols can do everything X can do, but can do it faster and with less latency. You don't see these used much on UNIX systems, but they do exist.

Third, Wayland has no networking built into its protocol, because that makes little sense. Wayland is a compositing and input manager, essentially. The Wayland protocol itself shouldn't be networked. However, unlike with some other desktop environments, Wayland does not really require that the server the client talks to is in the desktop itself. There's nothing precluding the application talking to a local Wayland server that is just a proxy to another server. This is how Wayland runs over X11, for instance, or Wayland in Wayland. Wayland also -- unlike X -- does not require a root window to exist in the server, so there's no need for every proxy'd instance of Wayland to have its own desktop. The proxy can easily work at a per-window level.

Finally, while there is no such proxy yet, the existence of more modern remote desktop protocols and Wayland's design allows for the creation of a very good remote desktop proxy that can be plugged in over SSH or run over the Net raw. Because Wayland does not mandate a whole desktop, this means you can easily and trivially get X11-like per-window remoting but with incresed efficiency. This does not exist because Wayland itself is still not even ready to be used locally on the desktop, and given the small number of developers working on Wayland (and that none of the "we need remoting" folks are contributing at all) it just makes sense on making Wayland ready for the simple case before spending time on the more complex case. This does NOT mean that Wayland can't be remoted, or that it never will be remoted; it just means that right now today there are more important things to work on in the Wayland ecosystem. Remoting will come later when those other tasks are completed.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 23:20 UTC (Mon) by daglwn (guest, #65432) [Link] (22 responses)

> The other responses are the usual "I have no idea what the hell I'm
> talking about" crap that always comes up with Wayland discussions. Let
> me spell it out quickly.

Your response indicates a similar knowledge gap.

> First, the network transparency of X in today's environment is not
> ideal.

But it works.

> The original X protocol is designed around server-side rendering. That
> doesn't happen anymore in today's apps.

This makes no sense.

Keith gets it wrong as well (from the article):

> "How many of these applications care about network transparency, which
> was one of the original headline features of X?

The apps DON'T care about network transparency. That's why it's "transparent." The USERS care a lot about it. I'm one of them. I do remote X from work all the time. Web applications aren't a replacement. VNC and other such solutions I've tried are painfully slow compared to remote X.

> Second, there are other networked protocols that are much much better
> for today's networks and today's applications.

Great! I'll consider Wayland complete and usable when it implements one of them.

> Remoting will come later when those other tasks are completed.

I hope that is possible later. It's often hard to add major fundamental features if they're not designed-in from the beginning.

And given the Wayland developers' open hostility to any mention of network transparency I, for one, am not hopeful.

I hope to be proven wrong.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 23:50 UTC (Mon) by flammon (guest, #807) [Link] (3 responses)

>Keith gets it wrong as well (from the article):

You mean Keith Packard get's it wrong? I don't think you know who Keith Packard is.

http://en.wikipedia.org/wiki/Keith_Packard

I'm fairly certain that Keith didn't get it wrong.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 0:43 UTC (Tue) by daglwn (guest, #65432) [Link] (2 responses)

I know who Keith Packard is. As expressed in the quote from the article, it appears he gets it wrong.

Lots of people talk about "applications" not needing network transparency. It's not applications that need it. Indeed, they don't even know about it.

It's users that need it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:07 UTC (Tue) by dgm (subscriber, #49227) [Link] (1 responses)

Have you ever written an X11 application? One using the actual Xlib? If you hadn't, go do it now, and you will find that in X11 the network is all but "transparent" to applications. The networked nature of X11 shows up left and right. For instance, usually the very first thing you learn when programming for X is that it reverses the usual meaning of "client" and "server".

So, X11 network transparency is more or less a myth. It's not transparent, and in most cases, it's not even networked.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:36 UTC (Tue) by jonabbey (guest, #2736) [Link]

"So, X11 network transparency is more or less a myth. It's not transparent, and in most cases, it's not even networked."

I've programmed in Xlib, as well as in Xt (ugh). It's true that programmers writing X apps have to program to X, which makes the network's presence pretty evident, but once you've done that, you get network support whenever a user wants to use it.

The fact that "in most cases it's not even networked" is true, but irrelevant. In most cases when I'm programming I don't touch the mouse, but that doesn't mean it'd be acceptable to get rid of it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 0:07 UTC (Tue) by alankila (guest, #47141) [Link] (12 responses)

This is a different meaning to word application. "Application" referenced to usage context such as car stereo system.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 0:46 UTC (Tue) by daglwn (guest, #65432) [Link] (11 responses)

If that is so, a better word would be "systems" or "devices" to avoid confusion.

In any event, it still does not take away from the hard truth that many users still work in a client/server architecture and indeed are likely to continue to do so as the client side gets thinner in thinner (phones, wristwatches, etc.).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 6:17 UTC (Tue) by raven667 (subscriber, #5198) [Link] (9 responses)

And I would be amazingly surprised if Weyland didn't get a decent remoting protocol, aside from VNC which is pretty much guaranteed, when it's widely deployed. Virtualized desktops and app servers are a decent business and I doubt they will shut Linux out of that market by arbitrarily blocking features. In fact I'm surprised anyone is giving any creedence to such assumptions, wouldn't it make more sense to take them at face value when the developers say that they just aren't that far along yet?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:44 UTC (Tue) by nix (subscriber, #2304) [Link]

That's what I was saying until yesterday, until people started saying that it was impossible to do crucial optimizations that would reduce a remoting protocol's bandwidth requirements to orders of magnitude below VNC, and that X has been doing for roughly ten years.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 15:12 UTC (Tue) by daglwn (guest, #65432) [Link] (7 responses)

No, I don't trust them because they keep saying no one needs it. This kind of thing has to be designed in at the beginning. It is absolutely fundamental to the way the system works.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 15:50 UTC (Tue) by nye (subscriber, #51576) [Link] (6 responses)

>No, I don't trust them because they keep saying no one needs it

Can you point to a single example of anyone saying that? All I've seen is people saying that the X11 protocol itself would be better replaced with a different remoting mechanism.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:24 UTC (Tue) by daglwn (guest, #65432) [Link] (5 responses)

Look at all the comments about "no one uses it."

Yes, a different remoting protocol would be great. But they're not considering it from the start and I have a very hard time believing this is something that an be retrofitted and perform in any reasonable fashion.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:42 UTC (Tue) by raven667 (subscriber, #5198) [Link] (4 responses)

As someone else pointed out ICA and RDP are both retrofits and both are very high performing. VMware View is also working on a high performing remoting protocol and there is SPICE and NX. There has been a lot of research done in last decade or so on how to design remoting protocols and they don't require the entire GUI toolkit on up to be specially designed to work well.

In any event Wayland seems like a much better base to start from in pretty much every way so I'm not going to disparage the work based on so many assumptions based on a lack of evidence or against the available evidence.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:50 UTC (Tue) by daglwn (guest, #65432) [Link] (2 responses)

> As someone else pointed out ICA and RDP are both retrofits and both are
> very high performing.

No, not in my experience.

If it can be retrofit, great, I'm all for it. But I am very skeptical that the Wayland people have any real intention to support remote operation at all given comments in the past and in this very article and its comments.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 19:43 UTC (Tue) by BlueLightning (subscriber, #38978) [Link]

In another comment you say you don't use Windows, which makes it hard to take your dismissal of ICA and RDP as performant protocols seriously.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 17:47 UTC (Wed) by intgr (subscriber, #39733) [Link]

> But I am very skeptical that the Wayland people have any real intention to
> support remote operation

But since it's a frequently requested feature, chances are that someone else will do it sooner or later. Wayland developers sound pretty open to the idea at least -- they even list some reasons why wayland remoting should work better than remote X.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:28 UTC (Tue) by nix (subscriber, #2304) [Link]

SPICE: I see a 500Kb/s bandwidth requirement when nothing at all is changing on the screen of my virtual machine. Yes, it's fairly fast at displaying stuff, but bandwidth-efficient that is not.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 9:33 UTC (Tue) by alankila (guest, #47141) [Link]

My opinion is that what we call thin client today would have been a thick client of yesteryear.

I'm not hell bent on this X protocol network transparency because in my opinion it's so annoyingly slow even through ssh compression. If NX has made any improvements to it then perhaps someone should care enough to bring them into core X. If that doesn't happen, well, that tells all about how much people really care about this feature (which is always brought up for some reason).

Additionally applications tend to depend on message bus & configuration services which may or may not currently tunnel correctly over the message bus... Currently tunneled applications come up looking differently themed, so I'd say the evidence indicates that people simply aren't serious about this network transparency feature.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 1:18 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

The apps DON'T care about network transparency. That's why it's "transparent."

Would that this were so. Unfortunately the latency and bandwidth properties of a network cable are very different from the latency and bandwidth properties of a local socket, so applications *do* have to care. If they are not written to e.g. minimize roundtrips, the allegedly transparent networking rapidly degrades to a sluggish mess. Try X11 over the Internet, or GL over a medium-latency WAN (50ms or so RTT) and you will soon see the problem.

This problem can be reduced by increasing the asynchronicity of the protocol and reducing mandatory roundtrips (which Wayland is doing), but it can never be eliminated. Completely transparent networking is physically impossible, sorry. (That's not to say that I don't like network-transparency as far as it does: I certainly will never be able to use Wayland as my main desktop until it supports it. But your argument is still wrong.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 1:23 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

the protocol designer and users care about latency and bandwidth, but the application programmer doesn't need to care.

what would the application programmer do different in their code depending on latency?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 3:23 UTC (Tue) by jengelh (subscriber, #33263) [Link] (1 responses)

>what would the application programmer do different in their code depending on latency?

For one, less eyecan{dy,cer} and decreasing the rate of updates to widgets such as progress bars. :-)

Then again, the toolkit should probably take care of that on a global scale.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 3:28 UTC (Tue) by dlang (guest, #313) [Link]

well, those tend to be good things in any case (and decrease battery use as well), if you are updating widgets (especially progress bars) so frequently that having them be on the other side of a 50ms latency is a problem, you are updating them to much as it is :-)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:31 UTC (Tue) by nix (subscriber, #2304) [Link]

The application programmer needs to care so as not to do things common on non-remotable systems such as repeatedly querying the screen or server for things. Luckily, with the increasing use of off-screen buffers, this is becoming uncommon anyway, but it used to be a plague.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 1:13 UTC (Tue) by nix (subscriber, #2304) [Link] (58 responses)

There's another major advantage of doing things this way which should perhaps be more emphasised. Right now, if we discover a more efficient protocol for remote display, we cannot use it with X because the clients talk the X protocol directly. If clients instead talked to a proxying compositor (pretending to be a Wayland server to the clients) which communicated across the network to a Wayland server on the local machine, we could fiddle that protocol in all sorts of ways for greater efficiency without ever needing to keep more than two pieces of software in sync (the proxy and the Wayland server itself).

Maybe all this hostility would go away if someone wrote this compositor and called it 'X12'...

Wayland - Beyond X (The H)

Posted Feb 14, 2012 1:20 UTC (Tue) by dlang (guest, #313) [Link] (29 responses)

Your plan only works if the improved remote protocol works with the Wayland API, you aren't eliminating a chokepoint API, just picking a different one.

If Wayland had a remote protocol, I would expect that x.org would gain support for it pretty quickly so that it would support clients written with X libraries and with Wayland libraries. It may even be enough of a change to become X12

but people with lots of experience in the field are saying that it's _really_ hard to retrofit network transparency

It's really hard to design good network transparency in the first place. X got it wrong by requiring too many round-trips, but even so it works well enough that people use it rather than taking the time to implement the nx proxies that would speed it up significantly

Wayland - Beyond X (The H)

Posted Feb 14, 2012 10:15 UTC (Tue) by khim (subscriber, #9252) [Link] (9 responses)

but people with lots of experience in the field are saying that it's _really_ hard to retrofit network transparency.

Who exactly says that and what exact experience do they have? RDP is retrofit - and it's one of the best remote access protocols in existence. Certainly better then what inborn X transparency offers.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 12:54 UTC (Tue) by renox (guest, #23785) [Link] (1 responses)

[RDP is retrofit - and it's one of the best remote access protocols in existence. Certainly better then what inborn X transparency offers.]

Best? I disagree: I remember that FreeNX is better for WAN access, and FreeNX is a 'wrapper' over X, AFAIK it's not possible to do the same thing over RDP.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 13:52 UTC (Tue) by nye (subscriber, #51576) [Link]

>Best? I disagree: I remember that FreeNX is better for WAN access

No *way*. In my experience its slower than RDP by at least an order of magnitude.

Be careful though that you're not making the mistake of comparing with RDP on Linux - RDP servers for X just stuff everything into a bitmap stream which really sucks compared to the native RDP in Windows; you're effectively just using a not-that-great VNC server.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 15:14 UTC (Tue) by daglwn (guest, #65432) [Link] (6 responses)

> and it's one of the best remote access protocols in existence. Certainly
> better then what inborn X transparency offers.

You're kidding, right? I find RDP to be painfully slow compared to remote X. Maybe that's because the applications I run lack a bunch of eye candy but that's what I experience.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 15:46 UTC (Tue) by nye (subscriber, #51576) [Link] (5 responses)

>I find RDP to be painfully slow compared to remote X

Could you give some details about the environment you're talking about? Is this over a local LAN? If not, what kind of latency and bandwidth are you talking about?

Also, when you're using RDP, are you talking about Windows remote desktop (or similar), or about an RDP server for X?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:27 UTC (Tue) by daglwn (guest, #65432) [Link] (4 responses)

I use remote X over both LAN and the 'net (previously DSL, now cable).

I connected to the KDE RDP service, which I assume is an RDP server for X. I don't care if it works better on Windows. I don't use Windows.

The problem with RDP is you send the whole damned desktop. I just want one or two applications. Yes, I know about single-window RDP. KDE doesn't seem to support it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:07 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

Well that's hardly much of a comparison, the RDP server for KDE is very unlikely to support anything more advanced than VNC, actually probably quite a bit less. When everyone is holding up RDP as an example protocol, they are talking about the native implementation on Windows so that is very much relevant to understanding the example.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:53 UTC (Tue) by daglwn (guest, #65432) [Link] (2 responses)

Now what did I say in my comment? Oh yeah, I don't use Windows.

Hey, if the Wayland people can retrofit a protocol, great. I have yet to see any real evidence that they intend to work on it but see lots of evidence they won't ("no one uses it" comments all over).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:09 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, you can get a Windows instance on Amazon S3 for a couple of bucks. Try to work in it using RDP, you'd be quite surprised.

I'm using RDP right now from Kiev (Ukraine) to work with my Windows compute nodes in California. Ping time is 220ms on average but it's definitely usable.

Plain X remoting is not usable at all. X11vnc is usable, but much more uncomfortable than RDP.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 12:15 UTC (Wed) by nye (subscriber, #51576) [Link]

>Now what did I say in my comment? Oh yeah, I don't use Windows

Then stop complaining loudly and insistently about the performance of something you've never even bothered to try.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:22 UTC (Tue) by farnz (subscriber, #17727) [Link] (17 responses)

Wayland's chokepoint API is much simpler than X11's, and provides much less; it's the Wayland proxies that get complex fast, but those are less constrained than Wayland itself. Retrofitting network transparency doesn't have to be hard - it's a problem that gets harder the more the protocol between hardware and user software is tied down.

Wayland's protocol is, at heart, very simple - you share buffers with the compositor and tell it when those buffers change, and the compositor tells you when you have input events to handle, giving you coordinates relative to your buffers. Your remoting proxy gets to work out what works on the network; while VNC is one possible remoting proxy (which just sends lightly compressed video across the LAN), as is X11, you can also have more sophisticated remoting proxies that understand what's going on at a semantic level, and send instructions accordingly (e.g. "here is enough of the current icon theme for you to render the widgets for this application. Now, put a RelativeLayout container in the window, with these child elements."). Yet another remoting proxy might simply implement enough EGL and OpenGL to allow you to forward the rendering command stream over the network.

Put simply, we know that X11 isn't the right protocol for local rendering or network transparency - it has flaws for both, and a lot of unfortunate history. Wayland is an attempt to keep the bits of X11 that make sense for local rendering, fix the baked in flaw around input handling, and leave the network transparency alone for someone else to deal with.

And finally, if network transparency is such a big deal, how come we ended up standardising on X11 and not NeWS? Note that NeWS is network-transparent over a much wider range of networks than X11 is, so if network transparency really mattered, we would be using a NeWS-like protocol, not X11.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:32 UTC (Tue) by rqosa (subscriber, #24136) [Link] (16 responses)

> Wayland's protocol is, at heart, very simple - you share buffers with the compositor and tell it when those buffers change, and the compositor tells you when you have input events to handle, giving you coordinates relative to your buffers.

Isn't that basically what already happens when you're running a DRI2-using X client along with a compositing window manager? So this feature isn't something that we don't already have.

> you can also have more sophisticated remoting proxies that understand what's going on at a semantic level, and send instructions accordingly

Sure, but in that case the applications (or rather the widget toolkit they use) must implement the protocol for this remoting proxy. And it seems like a remoting proxy server that serves native Wayland clients (according to your description of the protocol) couldn't really be more sophisticated than VNC. This is the real reason why people here are worried — articles like this one appear to be advocating "Porting the toolkit to Wayland", and so if the toolkit developers add support for native Wayland and drop support for X11, applications will no longer be able to run on sophisticated remoting systems like NX.

Now, if the toolkits were to add native support for some "sophisticated remoting proxies" (maybe RDP? maybe SPICE?) that give better performance than what's currently supported (NX, xpra, and plain remote X11), then that would be a real alternative to X11. But toolkits based on native Wayland are not an improvement over the status quo!

> fix the baked in flaw around input handling

I assume you're referring to the issue that the server (which handles input) can't convert screen coordinates to window coordinates in the case that the compositing window manager has transformed the window. But that is not a "baked in flaw" — X11 does not require the window manager to be a separate client, and indeed there are some X servers that can do the window management on their own.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:57 UTC (Tue) by raven667 (subscriber, #5198) [Link] (12 responses)

I don't think anyone is dropping support for X11 although X11 will probably go on life support with few enhancements and bugfixes only. X is used on all the proprietary systems and I don't see it "going away" any time soon just because something new shows up.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:49 UTC (Tue) by rqosa (subscriber, #24136) [Link] (11 responses)

> I don't think anyone is dropping support for X11

By "anyone", do you mean the toolkits (GTK+, Qt, EFL, etc.)? Because that's the real problem here — using Wayland only as a drop-in replacement for window managers probably wouldn't be a very disruptive change for end-users (at least for those who have hardware that's new/fast enough to do GPU-accelerated compositing), but using Wayland as a rendering back-end for widget toolkits is bad for end-users who depend on NX / xpra / remote X11 (unless the toolkits continue to support X11 alongside Wayland).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:56 UTC (Tue) by raven667 (subscriber, #5198) [Link] (10 responses)

Yes, that's what I mean, I don't expect X11 support to be dropped from GTK+, Qt, EFL, etc. just because those toolkits gain a Wayland output. In fact one could take advantage of Wayland when it's ready even without any direct toolkit support because X11 runs just fine on Wayland. I wouldn't be surprised if there is a long period of time where apps/toolkits are mix-n-match between X11 and Wayland native.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:13 UTC (Tue) by dlang (guest, #313) [Link]

running X apps on Wayland isn't the concern, everyone sees that this is possible today and so it's not something to bother anyone.

the problem if running a Wayland app on X (especially on a remote X display)

It's the new, small toolkits that people expect to be the problem, those are more likely to be Wayland only.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:51 UTC (Tue) by rqosa (subscriber, #24136) [Link] (8 responses)

> I wouldn't be surprised if there is a long period of time where apps/toolkits are mix-n-match between X11 and Wayland native.

But if the toolkits are going to drop X11 eventually, then they'd better replace it with something other than native Wayland, because a remote-proxy for native Wayland apps just can't have good performance.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:50 UTC (Tue) by jonabbey (guest, #2736) [Link] (7 responses)

NeWS on top of Wayland? ;-)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:02 UTC (Tue) by nix (subscriber, #2304) [Link] (6 responses)

I support this feature. I would support it even more if someone would come up with a NeWS with a sane language in the server, rather than DPS :)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:47 UTC (Tue) by rqosa (subscriber, #24136) [Link]

> NeWS with a sane language in the server

Maybe something like server-side QML / Qt Quick? (With the "server" also being a Wayland client, running on the same host as the Wayland server.)

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:19 UTC (Wed) by HelloWorld (guest, #56129) [Link] (3 responses)

What's wrong with Display PostScript? After all, the Code is not meant to be written or read by humans.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:50 UTC (Wed) by rqosa (subscriber, #24136) [Link] (2 responses)

Actually, NeWS application and/or toolkit developers were required to write PostScript code. I don't know all that much about it, but the way NeWS applications were split into server-side PostScript code and client-side C code seems kind of similar to modern "declarative UI" systems like in Qt, where there is a separation between the UI components (implemented in QML/JavaScript) and the application logic (implemented in C++). (Or for that matter, similar to Web applications using XMLHttpRequest and client-side JavaScript.)

(Note: the language is PostScript, not Display PostScript; DPS was not part of NeWS, but was an X protocol extension that allowed for server-side PostScript interpretation similar to what NeWS did.)

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:58 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

> Actually, NeWS application and/or toolkit developers were required to write PostScript code.
Really? My understanding was that toolkit developers had to write code that would then generate the PostScript code that would do the actual drawing, right? That is something very different from writing the PostScript code itself.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 2:21 UTC (Wed) by rqosa (subscriber, #24136) [Link]

Well, at least according to the Wikipedia article, "it was possible to write simple PostScript code that would result in a running, onscreen, interactive program", and "widgets ran all of their behaviour in the NeWS interpreter, and only required communications to an outside program (or more NeWS code) when the widget demanded it". And it goes on to describe the client/server architecture of modern web applications as being similar to that of NeWS, except with the JavaScript janguage in place of PostScript, DOM / HTML / the CSS box model in place of PostScript drawing commands, and JSON or XML in place of PostScript data expressions.

So, it would seem that toolkit and/or application developers did need to write PostScript, in the same way that web developers need to write JavaScript (and that Qt Quick app developers need to write QML/JavaScript).

Wayland - Beyond X (The H)

Posted Feb 16, 2012 19:11 UTC (Thu) by fuhchee (guest, #40059) [Link]

Javascript, certainly.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:11 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

That's the thing - Wayland isn't new features we don't already have - it's removing a whole pile of implementation details that are (in most cases) irrelevant to modern systems, but that cause maintenance trouble. Core fonts is just one example; subwindows are another example

Wayland can be viewed as providing the pieces to run X11 clients under a sane compositing X server. The remoting problem is simply being left alone, as it's known to be hard to get right (after all, X11 gets it wrong for modern systems, since the efficient way to do things is DRI2 and OpenGL ES 2.0, and OpenGL ES 2.0 has no serialization format of its own yet).

I note also that the systems you've cited in other comments where X servers include the window manager (Mac OS X, Exceed on Windows) are ones where X servers hand over rendering to a local rendering system - that's exactly the same situation as running a rootless accelerated X server as a Wayland client.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:25 UTC (Tue) by rqosa (subscriber, #24136) [Link] (1 responses)

> X11 gets it wrong for modern systems

It gets it right enough that many people are still using remote X11 for some tasks (see the subthread below). And there are also remote-proxying systems (NX and xpra) for X that provide better performance than VNC.

> (Mac OS X, Exceed on Windows) are ones where X servers hand over rendering to a local rendering system

Native Windows apps can use RDP, which gives better performance than VNC. (Mac OS X has Apple Remote Desktop; I'm not sure if that uses its own protocol, or VNC, or something else.) If the widget toolkits for Unix start using the Wayland native protocol and drop support for X11, then we'll lose the ability to use any remote-display protocols other than VNC-like ones.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 5:39 UTC (Wed) by khim (subscriber, #9252) [Link]

Mac OS X has Apple Remote Desktop; I'm not sure if that uses its own protocol, or VNC, or something else.

If you'll take a look on under the hood page you'll see that VNC figures quite prominently there. When used between two Macs it probably uses some additional extensions, but if you package lists Real VNC or OS9vnc in the list of compatible clients then you kind of know what protocol it uses, right?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:23 UTC (Tue) by nix (subscriber, #2304) [Link]

Your plan only works if the improved remote protocol works with the Wayland API

Er, yeah. That's why it's an improved Wayland protocol. Obviously. The compositor side is still a Wayland compositor.

If Wayland had a remote protocol, I would expect that x.org would gain support for it pretty quickly

I doubt it very much, at least if by that you mean the X server would. The X protocol's requirements are pervasive in the X server: you aren't going to get rid of them by waving a magic wand.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 10:32 UTC (Tue) by renox (guest, #23785) [Link] (27 responses)

Sorry nix but you seem to forget that the compositor see only "buffers" (images) or your application, so the compositor wont ever be able to do many optimisations that a toolkit or an application can do for remote access..

For example, one could imagine the display server would have a cache for the applications fonts managed by the client: the server gives the size of the cache at startup and then the client sends a texture of the most used glyphs, then most of the time the client wouldn't have to send again the image of the character.
How would you do this kind of optimisation in the compositor? You can't, what you can do only is compress the images..

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:12 UTC (Tue) by etienne (guest, #25256) [Link] (6 responses)

> one could imagine the display server would have a cache for the applications fonts managed by the client

I sometime wonder how much data is exchanged in between client and server, where both the server and the client have identical data locally stored.
For instance, why send fonts over the network, when both client and server have a local copy of the same font file (maybe because both are standard installation of the same Linux distribution).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:30 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

For instance, why send fonts over the network, when both client and server have a local copy of the same font file (maybe because both are standard installation of the same Linux distribution).

You have reinvented the X font server and core fonts. It turns out to be a pointless optimization: you gain the ability to remove one transfer of those glyphs of the font which are used (and only those glyphs) across the network. In exchange, you lose accurate client-side metrics, client-side compositing when needed (GlyphSets don't have to be composited on the server side, they just normally are); in current implementations the server has to pull the whole font in glyph by glyph so it's horribly slow with large Unicode fonts; you gain failure modes from the fonts claiming to be identical but not actually being pixel-identical, and validating that requires horrible hash-transfer handshakes...

Optimizing to speed up a transfer of a few hundred or a few thousand characters that occurs once in the life of a client is a waste of time. You're optimizing initialization! More important is that we not lose the ability to distinguish repeated units (like glyphs) and composite them on the server side... and judging from other comments here Wayland throws that baby out with the bathwater, leaving us with a protocol that must necessarily be far less bandwidth-efficient than X when displaying difficult images like a black-background xterm containing lots of text all in the same font. Because that trivial and common case is too hard to optimize! (boggle.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 16:48 UTC (Tue) by jonabbey (guest, #2736) [Link] (3 responses)

On the other hand, text on a solid background should be massively compressible, no? I suppose it would depend on the intelligence of the batching and delta protocol?

What bit-blitting for text rendering loses on a character-by-character basis it should presumably be able to gain in scrolling?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:05 UTC (Tue) by renox (guest, #23785) [Link] (2 responses)

The thing is: you want to do very fast compression..

On a system point of view, it's very stupid to loose all this information provided by the application: converting text to an image and then trying to compress the images generated..

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:35 UTC (Tue) by gioele (subscriber, #61675) [Link] (1 responses)

> On a system point of view, it's very stupid to loose all this information provided by the application: converting text to an image and then trying to compress the images generated..

On the other hand if you do not send rasterized text as image, you need to send text + fonts + other bits of information. In the past this approach has been found as limited and replaced by the current client-side font handling.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 12:51 UTC (Wed) by renox (guest, #23785) [Link]

You misunderstood me: I didn't advocate the old X way to do this, the XRender way to do fonts is quite good (client side glyph generation and a cache in the server): flexible and efficient for network transparency.

What I was saying that with Wayland the compositor will just see an image of the Window, so from a networking point of view this is not very efficient..

"Compressing" a window would be much more efficient if the background and the text were handled separatedly.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:37 UTC (Tue) by renox (guest, #23785) [Link]

Good remark, an interesting "corner case" optimisation but note that to be 100% sure that what the client and the server have is the same, you cannot trust filenames or version numbers: you'd need to checksum the content of the "supposedly shared" data..
Note that even when the client and the server have the same font files, there is a latency issue: the server doesn't know which font will be used, which means the first time a client refers to a font the server would need to access to a disk and disks are slow!

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:25 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

In that case the local protocol needs to grow. This optimization is crucial: it reduced the network hit of client-side fonts by many orders of magnitude at nearly zero cost. (Shoving huge bitmaps around on the local machine unnecessarily is going to hurt, too, with the memory hierarchy being what it is.)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 13:57 UTC (Tue) by renox (guest, #23785) [Link]

>Shoving huge bitmaps around on the local machine unnecessarily is going to hurt, too, with the memory hierarchy being what it is

No: they won't "shove" them around in their "normal" configuration, the client application render itself to a buffer in the GPU's memory then a reference to this buffer is sent to the display server which compose them: everything stays in GPU's memory, very efficient for the local case.

Of course this only work well if you have good HW and good driver, otherwise indeed this won't be very efficient..

Wayland - Beyond X (The H)

Posted Feb 14, 2012 14:40 UTC (Tue) by renox (guest, #23785) [Link]

> In that case the local protocol needs to grow. This optimization is crucial: it reduced the network hit of client-side fonts by many orders of magnitude at nearly zero cost.

This is very unlikely to happen as one of the design goal of Wayland is to allow the application to render itself anyway it chooses and then to work with buffers..

Wayland - Beyond X (The H)

Posted Feb 14, 2012 16:45 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

You might want to look at the Wayland protocol description - it's ~700 lines of XML, and reasonably comprehensible as-is.

A useful lie-to-children description of Wayland's protocol is that it's the bits of the X11 protocol that an application using XI2 for input and DRI2 for rendering will use.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 15:07 UTC (Wed) by renox (guest, #23785) [Link]

What is interesting also is the PDF "The Wayland Display Server"(*), it's much more readable..
It doesn't list exactly the same objects as the XML files, though.

*: http://people.freedesktop.org/~krh/wayland.pdf

Wayland - Beyond X (The H)

Posted Feb 14, 2012 14:14 UTC (Tue) by mjthayer (guest, #39183) [Link] (14 responses)

> Sorry nix but you seem to forget that the compositor see only "buffers" (images) or your application, so the compositor wont ever be able to do many optimisations that a toolkit or an application can do for remote access.

Is a buffer really just an image? I thought it was a handle, and farnz mentioned proxying EGL and OpenGL command streams above [1]. Which should take care of the font case quite nicely.

[1] http://lwn.net/Articles/481313/

Wayland - Beyond X (The H)

Posted Feb 14, 2012 16:01 UTC (Tue) by farnz (subscriber, #17727) [Link] (13 responses)

The Wayland compositor to Wayland client buffer is just a handle representing an image that the hardware already knows about. Wayland clients are where any network remoting will take place; for example, you could have a Wayland client that handles translating between Wayland and a serialised representation of GDK 3's events and commands. That serialised representation can then be carried over (for example) an SSH session to the Wayland proxy client, or to a Win32 proxy client that then uses native rendering to display the application.

This pushes the rendering to the Wayland end of the link - it deserialises the protocol the toolkit has chosen to do its rendering, and converts that to suitable drawing commands. Wayland, after all, has no built-in rendering of its own.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 10:28 UTC (Thu) by mjthayer (guest, #39183) [Link] (12 responses)

> The Wayland compositor to Wayland client buffer is just a handle representing an image that the hardware already knows about. Wayland clients are where any network remoting will take place [...]

Let's see if I have got a better idea now (after having looked at the Wayland architecture document[1] as well). It seems to me that to have an application render remotely one would need two different parallel connections: a remote OpenGL ES/EGL connection for the client to render over (is there such a thing currently?) and a connection from the client to the remote compositor to tell it about buffer updates. (And obviously the logical way to render fonts in such a set-up is to upload the glyphs to the remote display once and render them into your buffers using OpenGL ES commands.) Was that a bit closer?

Out of interest, my current understanding also suggests that the compositor and the server should be a single application. Is that right?

[1] http://wayland.freedesktop.org/architecture.html

Wayland - Beyond X (The H)

Posted Feb 16, 2012 10:47 UTC (Thu) by mjthayer (guest, #39183) [Link]

> Out of interest, my current understanding also suggests that the compositor and the server should be a single application. Is that right?

Taking my answer from "FOSDEM: The Wayland display server" in this week's LWN[1]:

"The code is divided in two parts: Wayland is the protocol and IPC mechanism, while Weston is the reference implementation of the compositor (and thus also the display server)."

So yes.

[1] http://lwn.net/Articles/481490/

Wayland - Beyond X (The H)

Posted Feb 16, 2012 11:06 UTC (Thu) by farnz (subscriber, #17727) [Link] (10 responses)

I'm going to try and answer you in reverse order - please bear with me.

Wayland is currently two things:

A protocol for communication between a compositing display server and local applications.
A library that implements that protocol, so that compositor implementers (e.g. Weston, Compiz, KWin) can concentrate on the hard stuff.

The compositor is the display server in Wayland's world - it will pass input events to applications, and accepts images from them for display.

My personal expectation is that an application that's rendering remotely will be split into two parts; one part (which I've been calling the rendering proxy) will run on the same machine as the Wayland compositor, and maintain two connections:

Wayland protocol to the local compositor.
TCP, SSH stream (to let SSH handle the security stuff for you) or other suitable socket type to the remote application, talking a private protocol.

The remote application will have one open socket, to the rendering proxy, and will serialise its rendering onto the network, and get events back from the proxy.

OpenGL ES has no serialisation form at all at the moment - it's an API that the client application calls. It shouldn't, however, be hard to write a rendering proxy that talks to a fake Wayland "compositor" and EGL library on the application machine, to forward all rendering across the network; there's just a lot of gruntwork there.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 18:11 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

>OpenGL ES has no serialisation form at all at the moment - it's an API that the client application calls. It shouldn't, however, be hard to write a rendering proxy that talks to a fake Wayland "compositor" and EGL library on the application machine, to forward all rendering across the network; there's just a lot of gruntwork there.

You can use Gallium3D for this. That's how SVGA (VMWare's 3D acceleration driver for guests) work.

But the amount of traffic is going to make it impractical.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 20:02 UTC (Thu) by mjthayer (guest, #39183) [Link] (5 responses)

> You can use Gallium3D for this. That's how SVGA (VMWare's 3D acceleration driver for guests) work.

To my knowledge (I have partly studied its programming documentation), SVGA emulates a graphics card with 3D capabilities, though with a much simpler register interface than an equivalent physical card. Gallium3D is a framework for writing (mainly DRI2) graphics drivers which VMWare use because the people who developed it are now their 3D engineering team. Gallium3D has been used for what you describe (see article on Phoronix [1]), though that only helps if you have a Gallium3D driver on the other side, and I don't think that Gallium3D presents any sort of stable API which might cause problems. I would have thought that directly proxying OpenGL ES might be a better idea (it has been specially developed for a small footprint as far as I can see), though Gallium3D might be useful for translating other APIs (like OpenGL + GLX) to OpenGL ES.

[1] http://www.phoronix.com/scan.php?page=news_item&px=OD...

Wayland - Beyond X (The H)

Posted Feb 16, 2012 23:43 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

>Gallium3D has been used for what you describe (see article on Phoronix [1]), though that only helps if you have a Gallium3D driver on the other side

There's no need for Gallium3D driver on the host side. Indeed 3D guest acceleration in VMWare works fine with NVidia blob or even DirectX on Windows.

>I would have thought that directly proxying OpenGL ES might be a better idea (it has been specially developed for a small footprint as far as I can see), though Gallium3D might be useful for translating other APIs (like OpenGL + GLX) to OpenGL ES.

Direct proxying has some problems. It's way too expensive for one thing, try to run APITrace ( http://zrusin.blogspot.com/2011/04/apitrace.html ) and see it for yourself.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 12:52 UTC (Fri) by mjthayer (guest, #39183) [Link] (3 responses)

> There's no need for Gallium3D driver on the host side. Indeed 3D guest acceleration in VMWare works fine with NVidia blob or even DirectX on Windows.

Right, but as I said VMWare's 3D pipeline isn't intimately tied into Gallium3D. They presumably used Gallium3D to develop the drivers because that was what they knew well, given that they (the ex-Tungsten Graphics team) had spent the last several years developing it. In theory it would work just as well without, though it may be (I haven't looked at the register interface that closely) that their virtual hardware is designed to be a good match for Gallium3D. Which wouldn't be very surprising, as that was designed to be a good match for current physical hardware.

> Direct proxying has some problems. It's way too expensive for one thing, try to run APITrace ( http://zrusin.blogspot.com/2011/04/apitrace.html ) and see it for yourself.

Does that go for OpenGL ES 2 as well? I thought it was OpenGL stripped to the minimum that makes sense for modern graphics cards (mainly shader stuff). I haven't looked at Gallium3D that closely yet, but my feeling was that its "API" isn't all that different to OpenGL ES 2. Except that OpenGL 2 is a fixed interface whereas Gallium3D is still rather blurry and changing. If you know more than me I am very interested to know.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 16:40 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

>Right, but as I said VMWare's 3D pipeline isn't intimately tied into Gallium3D.
But it is. Even their Windows guest 3D driver is based on Gallium3D.

>They presumably used Gallium3D to develop the drivers because that was what they knew well, given that they (the ex-Tungsten Graphics team) had spent the last several years developing it.
Well, there's a reason they bought Tungsten Graphics in the first place.

>Does that go for OpenGL ES 2 as well? I thought it was OpenGL stripped to the minimum that makes sense for modern graphics cards (mainly shader stuff).
Yes, unfortunately. OpenGL ES2 is just as big for real cases.

>I haven't looked at Gallium3D that closely yet, but my feeling was that its "API" isn't all that different to OpenGL ES 2.

Gallium3D is not really an API, it's more of a good intermediate model for other things. Sort of like LLVM is a nice layer for other stuff.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 17:02 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

>>Right, but as I said VMWare's 3D pipeline isn't intimately tied into Gallium3D.
>But it is. Even their Windows guest 3D driver is based on Gallium3D.

But surely this is because the purpose of Gallium3D is modularising graphics driver code and letting you reuse as much code as possible in different drivers? So that the approach would have been just as valuable if they were targeting a traditional graphics card rather than a virtual pass-through device?

>>I haven't looked at Gallium3D that closely yet, but my feeling was that its "API" isn't all that different to OpenGL ES 2.
>Gallium3D is not really an API, it's more of a good intermediate model for other things.

Well Gallium3D's interface on the hardware side if you like. That is one reason I wrote "API" in quotes.

Wayland - Beyond X (The H)

Posted Feb 18, 2012 4:06 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

>But surely this is because the purpose of Gallium3D is modularising graphics driver code and letting you reuse as much code as possible in different drivers? So that the approach would have been just as valuable if they were targeting a traditional graphics card rather than a virtual pass-through device?

There are no "traditional graphics cards" anymore...

Besides, what are you going to target? What if you target NVidia cards and your host has an ATI card?

So you have to build a translation layer somehow. You can do this on API level (like VirtualBox guest addition do) but with shaders and OpenCL it's a doomed proposition. Gallium3D allows to build a virtual abstract graphics card and use usual mechanisms like OpenGL or DirectX to work with it.

>Well Gallium3D's interface on the hardware side if you like. That is one reason I wrote "API" in quotes.
You can talk to hardware without Gallium3D (indeed, Intel's 3D drivers do not use it). Gallium3D is more of a user-space abstraction to translate OpenGL/OpenCL/vdpau into a stream of abstract commands (TGSI command stream) which then can be translated into graphic card's native command format.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 2:09 UTC (Fri) by obi (guest, #5784) [Link] (2 responses)

does that mean you'd have to write a "rendering proxy" for every rendering API that could possibly be used? ie. cairo, opengl, whatever obscure graphics library a future Wayland client might decide to use?

Wayland - Beyond X (The H)

Posted Feb 17, 2012 5:02 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

No, obscure old libraries are unlikely to be ported to Wayland and would just run inside a hosted X-server.

Alternatively, they can fall back to a generic VNC-like protocol.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 12:56 UTC (Fri) by mjthayer (guest, #39183) [Link]

I thought that these days most graphics/GPU/GPGPU stuff could be expressed using buffers and shaders anyway, so that you could encapsulate it in OpenGL ES 2 if you wanted. Similar to what Gallium3D is doing, to bring it into this thread too.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 9:15 UTC (Tue) by daniels (subscriber, #16193) [Link]

Nailed it. Thanks.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 0:19 UTC (Tue) by iabervon (subscriber, #722) [Link] (9 responses)

People haven't really used X's network transparency for over a decade, because it's horribly insecure. Instead, they run a thin X server on the remote machine, connect it to a local X client over an ssh connection, and remote applications are none the wiser. Replacing either or both of the X protocol interactions with Wayland is pretty irrelevant, and actually even benefits from cutting out the local X server and compositor between ssh (locally) and the display hardware.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 0:23 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

if you are remoting things via ssh, you don't have to run a thin X server on the remote machine.

given the number of people who say they use this feature, saying that nobody has used it in a decade seems to be sadly mistaken.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:56 UTC (Tue) by aleXXX (subscriber, #2742) [Link]

We use remote X too at work.

Alex

Wayland - Beyond X (The H)

Posted Feb 14, 2012 0:52 UTC (Tue) by daglwn (guest, #65432) [Link] (1 responses)

> People haven't really used X's network transparency for over a decade,

Baloney. I use it regularly.

> Instead, they run a thin X server on the remote machine, connect it to a
> local X client over an ssh connection, and remote applications are none
> the wiser.

In other words they run the remote X protocol over a secure link.

> Replacing either or both of the X protocol interactions with Wayland is
> pretty irrelevant

How so? The applications talk the X protocol. Once they're ported to Wayland, they can no longer do remote X, whether over ssh or not. They'll only be able to have network transparency if Wayland implements it, about which the project members have clearly indicated they do not care one bit.

Wayland - Beyond X (The H)

Posted Feb 21, 2012 0:41 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]

Once they're ported to Wayland, they can no longer do remote X, whether over ssh or not.

Not necessarily. At least Gtk+ 3 supports selection of the Gdk back-end at initialisation time, so the same binaries can speak both Wayland and X.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 14:22 UTC (Tue) by tnoo (subscriber, #20427) [Link] (4 responses)

> People haven't really used X's network transparency for over a decade, because it's horribly insecure.

Wrong assumption. Our lab uses this on a daily basis. We usually purchase one or two fast machines per year, but everybody has access to its computing power if needed. By using X over the network (security is not an issue, especially not if using ssh -X).

And how would you work on any HPC compute server without X? There's more usecases for Unix than your grandma's desktop computer.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 15:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

We're using Amazon for the HPC work and do just fine with x11vnc (we use it to access Cluster Compute Eight Extra Large Instances). Raw X11 is just unusable.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:18 UTC (Tue) by iabervon (subscriber, #722) [Link] (2 responses)

If you're using ssh -X, you aren't using X's network transparency. The applications are connecting to a local-to-them proxy (localhost:10 or something) which is part of sshd, and this results in a connection by a local-to-you proxy (part of ssh) connecting to your actual X server. Now, sshd/ssh's implementation is potentially simplified by the fact that the same protocol is used in each place, but there's no fundamental reason that it has to be. In fact, you may lose performance because applications have to make an inefficient stream of requests to get the effects they want when speaking the X protocol; you may actually do better to have Wayland clients talk to an sshd-provided back end which uses the graphics hardware on the fast server to render stuff and sends the window images via the X protocol over the ssh connection back to your local ssh which can paint (and composite) them with Wayland.

This is, of course, even assuming that Wayland (or openssh) never comes up with a way to send Wayland traffic over a network connection. It also assumes that you never run "special" X applications remotely; you'll be sad if you run your window manager or compositor on the fast server (but you'd already be sad with respect to performance), and you may not be able to take screen shots of other windows from an application running on the fast server (if you want to use GIMP to take a screenshot, you'd have to run GIMP locally, not remotely).

But for the normal case of running a self-contained graphical application remotely, there should be no need for the application to communicate with anything non-local.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:26 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

using ssh -X is absolutly using the network transparent functions of X. The X protocol is being run over a network. That network happens to be a VPN over another network, but it's all network TCP communication that's allowing this to happen.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:13 UTC (Tue) by nix (subscriber, #2304) [Link]

Quite. ssh -X would not be usable as an X transport if X were not already implemented as a network-transparent, network-layer-independent communications protocol.

What ssh is ditching is the X authentication and (nonexistent) transport encryption layer, which I would agree heartily is a good idea.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 6:23 UTC (Tue) by koch (subscriber, #55163) [Link]

I've been using xpra ("screen for X") at work lately, because I found it annoying to loose all my windows when the network went down. If I've understood it correctly, xpra works by scraping off windows from a compositing dummy X-server, and presenting them over the network. I never liked the idea of importing a full desktop like with VNC,

I haven't looked closely at the Wayland architecture yet, but I would prefer something like Xpra over X-forwarding or VNC. Hopefully it shouldn't be too hard to implement.

Wayland - Beyond X (The H)

Posted Feb 13, 2012 21:56 UTC (Mon) by dcg (subscriber, #9198) [Link] (6 responses)

Wayland, Btrfs, systemd, Pulseaudio...not your grandfather's Linux!

Wayland - Beyond X (The H)

Posted Feb 13, 2012 22:21 UTC (Mon) by neilbrown (subscriber, #359) [Link] (1 responses)

> Wayland, Btrfs, systemd, Pulseaudio...not your grandfather's Linux!

May I restate that?

Linux, Wayland, Btrfs, systemd, Pulseaudio .... this is not the Unix that I remember!

Wayland - Beyond X (The H)

Posted Feb 13, 2012 23:25 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Sure, grandpa, sure 8-)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 0:09 UTC (Tue) by bronson (guest, #4806) [Link] (3 responses)

The Change Train is now boarding at platform 3.2. Destination: The Future and points beyond.

Leave your baggage behind. All aboard!

Wayland - Beyond X (The H)

Posted Feb 14, 2012 0:11 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

if it was just leave your baggage behind people wouldn't mind as much.

but when you also insist that they leave their tools, workflows, and features behind it becomes a problem.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 5:40 UTC (Tue) by theophrastus (guest, #80847) [Link] (1 responses)

exactly. if i can do what i want to do with the next wave of change, then i'm ok with it. it's when someone declares: "why would you want to do that? nobody does that!" (perhaps inserting a gratuitous ageist remark) "no, you won't be able to do that." (sometimes: "not in the first release") "...and there's no reason to do that when you can do *this*" that is when the change starts to seem gratuitous and resistance is discovered.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 19:18 UTC (Wed) by jedidiah (guest, #20319) [Link]

> "why would you want to do that? nobody does that!"

Sounds like a gaggle of Mac users. If I wanted that, I would just use a Mac.

There's some irony here...

Posted Feb 13, 2012 22:28 UTC (Mon) by oldtomas (guest, #72579) [Link] (47 responses)

Reading this (at the top of page 3)

Networking applications can be replaced with remoting tools such as RDP or VNC or are better performed in a browser.

And then, a couple of sentences further

Linux is famously scalable between devices but as Keith Packard points out: "[...] developers designing these systems are more likely to resent X for its complexity, for its memory and CPU footprint [...]"

At the moment my firefox is 123m RES vs 48m RES for X (and that's with a very moderate Firefox usage).

It feels strange to watch clients gravitating more and more to the bloated so-called "thin client" (I mean: HTTP as transport? XML as data serialization? [OK, the very smart ones have discovered JSON for that] Seriously?) and on the other hand hearing complaints about the inefficiency of the X server.

Just sayin'

There's some irony here...

Posted Feb 13, 2012 22:44 UTC (Mon) by dlang (guest, #313) [Link] (46 responses)

yes many apps do turn up the eye candy to the point where sending a video feed is just as efficient.

but that's not all apps.

the sort of apps that work best as a video feed aren't ones that you would normally want to remote in any case.

this seems to be throwing out the baby with the bathwater.

There's some irony here...

Posted Feb 13, 2012 23:54 UTC (Mon) by Kit (guest, #55925) [Link] (45 responses)

The Wayland protocol wouldn't necessarily require virtually streaming a video to the remote side.

Weston (the reference implementation, equivalent of Xorg, as opposed to the protocol Wayland, equivalent of X11) could be replaced (or just extended) in instances where one wants to display the application on a remote system with a compositor that leverage various techniques to reduce the bandwidth consumption. It could use many of the techniques that NX uses (compression and caching), so it would likely end up with similar performance. It shouldn't be too hard to beat plain Xorg running more modern apps, since they more and more operate in manners that isn't ideal for the network transparency of X11.

There's some irony here...

Posted Feb 14, 2012 0:02 UTC (Tue) by dlang (guest, #313) [Link] (44 responses)

sending a series of screenshots to the remote side is roughly the equivalent of sending a video, but without the compression advantages that the streaming video formats provide.

There's some irony here...

Posted Feb 14, 2012 0:37 UTC (Tue) by Kit (guest, #55925) [Link] (42 responses)

Sending a series of screenshots is exactly what I meant that it didn't have to do.

Since the compositor is notified whenever the application changes what it has drawn, the compositor could then just do a comparison of the last sent frame and send only the delta, which under normal conditions would greatly reduce the bandwidth needed. Throw in some intelligent caching (like what NX or RDP does- although it would be harder to be as intelligent based on my understanding of the protocol), and the bandwidth used could potentially be lowered by even more.

I would imagine a 'worst case' situations would be smooth-scrolling in a large window (like a browser), but that would also be a case that X handles similarly poorly.

I'm glad that the debate isn't over "is network transparency even possible" anymore, but to "how well can the performance of the network transparency be".

There's some irony here...

Posted Feb 14, 2012 0:54 UTC (Tue) by dlang (guest, #313) [Link] (4 responses)

there was never a question of if it is possible, the question is if the Wayland developers would bother to do so, or would declare such capabilities 'obsolete' and not needed in the modern world.

Frankly, I expect that in the near future network transparancy will start to be more used as people have devices with high resolution, but low CPU and memory (i.e. tablets and phones with HD displays, connected to projectors for example) where it will be desirable to run the app on a good server and remote the display and controls the the user.

This may not be practical over the Internet, but on a local (even local wireless) network this should work very well.

There's some irony here...

Posted Feb 14, 2012 0:58 UTC (Tue) by daglwn (guest, #65432) [Link] (1 responses)

> Frankly, I expect that in the near future network transparancy will start
> to be more used as people have devices with high resolution, but low CPU
> and memory (i.e. tablets and phones with HD displays, connected to
> projectors for example) where it will be desirable to run the app on a
> good server and remote the display and controls the the user.

I share this vision. Someone ought to be able to run a media server in the home and watch videos, etc. on handheld devices without requiring gobs of processor. There will never be enough processing power on embedded devices to keep up with what users will demand of their displays.

I expect it will even be done over the internet someday.

There's some irony here...

Posted Feb 14, 2012 1:05 UTC (Tue) by dlang (guest, #313) [Link]

videos are a special case where hardware implementations of the common algorithms can be built that allow low-power devices to keep up with the decompression load.

but that still leaves a huge number of other applications

There's some irony here...

Posted Feb 14, 2012 22:21 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

by the way, one place that we are seeing people talk about what use cases that should be trivial if you are using a display protocol that's got transparent network features is where people are talking about using their HD TV as a display running content off of other devices (sliding a window from a tablet to a TV and similar)

with X and xpra for example, this is should be a trivial thing to do, instead you see it as the latest 'gee wiz' feature of closed proprietary systems that can only remote specific types of content.

There's some irony here...

Posted Feb 14, 2012 22:42 UTC (Tue) by khim (subscriber, #9252) [Link]

with X and xpra for example, this is should be a trivial thing to do, instead you see it as the latest 'gee wiz' feature of closed proprietary systems that can only remote specific types of content.

The most useful example includes watching video (you watch video on the tablet, then drag it to HDTV if you like it) or turning the tablet off when you've dragged "content" to HDTV. Or just simple change of controls when you drag the window (the controls suitable for tablet are removed and remote-friendly controls are installed). Sure it's easy to create 90% of the whole solution with X and xpra, but I doubt people will be content with it. And to reach 100% solution you'll need help from application side anyway.

There's some irony here...

Posted Feb 14, 2012 0:56 UTC (Tue) by daglwn (guest, #65432) [Link] (10 responses)

> I'm glad that the debate isn't over "is network transparency even
> possible" anymore,

That was never really the question. The question has been and continues to be, "will we bother to implement network transparency?"

It seems so far the only answer ever give is, "no."

dlang is right. It IS throwing the baby out with the bathwater and it IS removing necessary features and disrupting common workflows.

"Not now" vs "No"

Posted Feb 14, 2012 16:33 UTC (Tue) by CChittleborough (subscriber, #60775) [Link] (9 responses)

The question has been and continues to be, "will we bother to implement network transparency?" It seems so far the only answer ever given is, "no."

Actually, Kristian Høgsberg, Adam "Ajax" Jackson and others have all written about ways to provide network transparency in the future. For the present, the Wayland/Weston developers are concentrating on getting the protocol right and providing a first implementation.

Once this is done, they plan to produce a production-quality X-server-as-a-Wayland-client, AFAICT. (They've already demo'd X-on-Wayland, but ISTR that those were not production-quality.)

In the longer term, we already have proof-of-concept implementations of network-transparency in the form of VNC, Spice, Xpra, etc. These use various approaches; the "Remote Wayland" project would need to select an approach, design a network protocol and write some non-trivial software, which will take some time, but success is basically guaranteed if vendors provide enough resources.

"Not now" vs "No"

Posted Feb 14, 2012 17:35 UTC (Tue) by daglwn (guest, #65432) [Link] (8 responses)

> Wayland/Weston developers are concentrating on getting the protocol right

How can they be sure the protocol is right if they don't consider network transparency from the start?

I'm fine with alternate solutions as long as they perform as well or better than remote X and are as easy to use (ssh -X). I'm doubtful that will happen if it's not designed in from the start.

"Not now" vs "No"

Posted Feb 14, 2012 20:59 UTC (Tue) by wmf (guest, #33791) [Link] (1 responses)

They have considered it; they just haven't implemented it. (There is a concern that nobody will provide funding and it will never get implemented.)

"Not now" vs "No"

Posted Feb 15, 2012 1:32 UTC (Wed) by daglwn (guest, #65432) [Link]

That's exactly the problem.

Network transparency will need a second protocol

Posted Feb 15, 2012 9:14 UTC (Wed) by CChittleborough (subscriber, #60775) [Link] (5 responses)

I should have made myself clear; sorry. In the sentence daglwn quoted, I meant the non-networked protocol for use between apps and Wayland servers running on the same system. That protocol involves sharing graphics buffers via the kernel, so it can never be network-transparent. The devs have released 1.0, so they must think they've got that protocol about right.

Network transparency will require a second protocol which sends some kind of image deltas from the app to the server. Choosing how to do those deltas will take some time, but should pose no insurmountable challenges.

Network transparency will need a second protocol

Posted Feb 17, 2012 10:09 UTC (Fri) by jezuch (subscriber, #52988) [Link] (4 responses)

> Network transparency will require a second protocol which sends some kind of image deltas from the app to the server. Choosing how to do those deltas will take some time, but should pose no insurmountable challenges.

My impression was that the Wayland protocol is already all about deltas: applications update the buffer and tell Wayland what changed (i.e. what it the delta). Pushing those via network seems trivial. Is my impression wrong?

Network transparency will need a second protocol

Posted Feb 17, 2012 12:24 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

Devil is in details. Some trivial (and fast in local case!) effects (think fade-ins when you try to pull list on Android beyond it's limit) can generate literally tons of update messages. And this is exactly the type of effects which Wayland is suposed to make sensible!

Network transparency will need a second protocol

Posted Feb 24, 2012 16:17 UTC (Fri) by wookey (guest, #5501) [Link]

'literally tons'.

I never realised messages had so much mass. How come the handset doesn't get really heavy after a while - does the excess weight get sent to the base-station posts where it can disspate harmlessly?

Local Wayland protocol does not use deltas

Posted Feb 18, 2012 11:25 UTC (Sat) by CChittleborough (subscriber, #60775) [Link] (1 responses)

The Wayland protocol does not use deltas. The server (=compositor) maintains a graphics buffer and gets the graphics hardware to display it. When a client wishes to change the display (eg., because of user input), it renders into its own graphics buffer (=window) and then tells the server (=compositor) about the damage region(s). The server can then update the visible graphics buffer. The aim is that the visible buffer is always what you would get if you composited the client buffers according to window position etc, but the server only processes the parts of client buffers that have changed.

Local Wayland protocol does not use deltas

Posted Feb 20, 2012 11:24 UTC (Mon) by etienne (guest, #25256) [Link]

Is that the case that so much eye-candy has been added to the desktop (xterm with transparent background,...) that remote desktop cannot handle that amount of display primitives, and the system has to deal with bitmap only, sampled after the visual effect are finished?
It seems that, on a very high latency network, we may want simple display primitives, and use font, graphic, buttons, mouse shape, background locally stored (when their UUID is available locally)...

There's some irony here...

Posted Feb 14, 2012 1:09 UTC (Tue) by dlang (guest, #313) [Link] (14 responses)

something as simple as moving a window around will produce a huge delta.

Also, you can only use the GPU on a box if you limit yourself to one display per box, if you have several remote displays going on, sharing the GPU becomes a limiting factor.

being able to leverage remote GPUs for the display would be a very good thing, but unless you design it in to the protocol early, you are very unlikely to be able to retrofit it and have it work sanely.

There's some irony here...

Posted Feb 14, 2012 1:55 UTC (Tue) by Kit (guest, #55925) [Link] (13 responses)

> something as simple as moving a window around will produce a huge delta.

Only if you're following the VNC "whole-desktop" model, and would likely require extra work.

The logical way (at least IMO), would be to treat all the applications as distinct objects, with their own damage events. The computer you're sitting at would take all the windows its getting from the remote system, and then composite them on to the screen. Just like how XComposite made it so applications wouldn't have to redraw themselves whenever a window was moved above it, this would enable the compositor running across the internet from you to not care if you were moving the windows around the screen like a madman.

Then there would be no delta from moving a window around (well, unless you're talking about a sub-window in an MDI application...).

> being able to leverage remote GPUs for the display would be a very
> good thing, but unless you design it in to the protocol early, you
> are very unlikely to be able to retrofit it and have it work sanely.

Since applications render into an off-screen buffer, that is then passed to the Compositor (Weston, in the case of the current one), which then paints it to the screen. At least at a high level, this should be quite conducive to using remote GPUs (well, assuming 'remote' is the system the application is running on, not the system you're sitting at- beyond whatever the local compositor decides to do when it's doing the final screen painting).

There's some irony here...

Posted Feb 14, 2012 2:44 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

>> something as simple as moving a window around will produce a huge delta.

> Only if you're following the VNC "whole-desktop" model, and would likely require extra work.

remember that the Wayland people are the ones saying that the solution to network transparency is VNC.

There's some irony here...

Posted Feb 14, 2012 5:49 UTC (Tue) by Per_Bothner (subscriber, #7375) [Link] (4 responses)

remember that the Wayland people are the ones saying that the solution to network transparency is VNC.

No, they're saying a solution is something like VNC. Using VNC is useful because it supports multi-platform remoting, but a protocol tuned for Wayland would obviously be more efficient for Wayland-to-Wayland remoting. But designing and implementing the protocol is not a priority until the local case is stable - as long as they keep the issue in mind, which they seem to be doing.

There's some irony here...

Posted Feb 14, 2012 6:02 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

Apparently it is more fun to make strong statements based on selective misreading rather than have an actual discussion. Argument by vehemency. Personally i am surprised no one has mentioned SPICE as a possible candidate for Weyland remoting although maybe the NX folks will come out with something neat. VNC is pretty much guaranteed to be supported in any case. Also it's not like X11 will magically disappear overnight, all the current toolkits will probably continue to work for the foreseeable future and there is no problem running X11 on Weyland, much like how X11 runs on other systems

There's some irony here...

Posted Feb 14, 2012 6:30 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

the concern is not about the difficulty in running X11 apps on a Wayland server. That works today (plus if it didn't work, Wayland would be pretty hard to bootstrap)

the concern is getting future killer app Y that was built with a Wayland graphics library to run on a system that uses X11 for it's display. This will probably start to be a problem a few months after Fedora and/or Ubuntu ship with Wayland as the default display instead of X11 (not that the killer app will need anything that Wayland provides, it's just that it will be build using the new 'cool and trendy' graphics library.

or alternatively, make it so that you can use Wayland in the places where people currently use X11 network transparency.

There are a lot of people writing infrastructure code for Linux that don't seem to have any Unix experience. This doesn't have to be a bad thing, but when these people dismiss existing functionality as "nobody could ever want that", it then becomes a problem. Especially if this work goes in to a major distro.

There's some irony here...

Posted Feb 14, 2012 7:03 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I dunno, I would still expect apps to use toolkits such as QT or GTK+ which can output to several different kinds of graphics drivers, including X11. I suppose if someone did write a "killer app" which didn't use a toolkit and was directly speaking the Weyland protocol and you didn't want to run it over VNC and a high performance remote display protocol hadn't yet been implemented then that could be a problem. That's a fair number of "ifs" though.

There's some irony here...

Posted Feb 14, 2012 9:20 UTC (Tue) by daniels (subscriber, #16193) [Link]

There are a lot of people writing infrastructure code for Linux that don't seem to have any Unix experience.

As far as I can tell these days, True UNIX Experience is limited to those who exclusively comment on LWN, Reddit and Hacker News, rather than those who write code.

There's some irony here...

Posted Feb 14, 2012 8:56 UTC (Tue) by marm (guest, #53705) [Link] (6 responses)

> Only if you're following the VNC "whole-desktop" model, and would likely require extra work.

Well, and what about scrolling the contents inside a window?

There's some irony here...

Posted Feb 14, 2012 9:47 UTC (Tue) by alankila (guest, #47141) [Link] (5 responses)

This keeps on being brought up.

While I don't know if it will ever get done, nothing at all would prevent an application from supplying the display system a rendering hint that says: "in my window texture, at rectangular region (x1, y1) to (x2, y2), the contents are shifted up by z pixels". It would do this at the same time when it pushes an updated texture for the compositor.

Now suppose remoting is done through a dumb transmit-pixel-images kind of protocol. A hint like this would allow the compositor to send this event to the remote display followed by the z rows of data which appeared at either top or bottom, thus achieving what must be the optimum efficiency.

These events could be generated by the relevant toolkits when they can prove that the proposed optimization is valid. Things like fixed backgrounds in scrollable areas would break this kind of optimization, although ways would exist to get around even that (instead of working with the single fully rendered window texture, work with the individual textures that comprise the UI elements, so a textarea is one texture at specific coordinates laid over a background texture, etc.).

There's some irony here...

Posted Feb 14, 2012 10:30 UTC (Tue) by marm (guest, #53705) [Link]

That's a neat idea. If it will ever get done, as you say... I agree that X11 has grown to an unsustainable state, but I still have a sad feeling that Wayland is motivated much more by eye candy than by usability. But let us see.

There's some irony here...

Posted Feb 14, 2012 21:56 UTC (Tue) by HelloWorld (guest, #56129) [Link] (3 responses)

> While I don't know if it will ever get done, nothing at all would prevent an application from supplying the display system a rendering hint that says: "in my window texture, at rectangular region (x1, y1) to (x2, y2), the contents are shifted up by z pixels". It would do this at the same time when it pushes an updated texture for the compositor.
This is precisely the sort of stuff that doesn't belong in Wayland. If you add things like this, it is all too tempting to add things like an optimization for lines being drawn and one for characters being drawn and oops, you just invented a new rendering protocol.
That isn't necessarily a bad idea, but it should be done separately.

There's some irony here...

Posted Feb 15, 2012 19:15 UTC (Wed) by alankila (guest, #47141) [Link] (2 responses)

Well, whatever way the remoting gets done. Not saying it has to be in Wayland's protocol, just saying that reasonably efficient scrolling is possible given that somebody who knows how the display changed will tell the information, rather than loses it and then requires some expensive rediscovery process to happen...

There's some irony here...

Posted Feb 15, 2012 19:20 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

Well, this is exactly what Høgsberg is saying: network transparency should be implemented in the toolkit, because the toolkit has access to the relevant information.

There's some irony here...

Posted Feb 15, 2012 19:24 UTC (Wed) by dlang (guest, #313) [Link]

but if it's only implemented in each toolkit, then you will end up with a nightmare of different remoteing protocols, and the resulting compatibility issues that this raises.

and what happens if one of these toolkits doesn't support the display mode on your platform (since each toolkit will need to write a sender and receiver for it's protocol)

There's some irony here...

Posted Feb 14, 2012 1:21 UTC (Tue) by nix (subscriber, #2304) [Link] (10 responses)

Quite. I would expect that with minimal observation of the damaged regions (or perhaps with a little more information from the client) the 'network compositor' could detect regions which are repeatedly reused and transmit them once to the far end, following which it only needs to send 'put that here'. (This is similar to what X does with GlyphSets, only automated.)

If the clients can communicate some indication as to which elements are likely to be repeated (as they do with GlyphSets) this changes from a relatively expensive pattern-recognition job to something utterly trivial -- and, for textual display at least, the bandwidth savings would be immense. (Who complains about the network bandwidth usage of client-side fonts? Nobody, that's who, because they don't need much because of precisely this trick.)

There's some irony here...

Posted Feb 14, 2012 10:06 UTC (Tue) by alankila (guest, #47141) [Link] (9 responses)

If Wayland will be properly optimized for local usage, the clients render directly into GPU memory which precludes having a fast access to the pixels of the window. (CPU reading from GPU memory is very slow.) I'm personally hoping that this will be the case, either through applications writing the pixels to GPU texture directly, or applications using GPU's hardware to draw the primitives, or both.

In theory, window textures can be snapshotted/copied to main memory and any analysis can be performed there, but I'd personally rather see application level remoting because for pretty much all open source software that exists, it only needs to be done twice: to GTK+ and Qt, and doesn't even depend on Wayland being used (you could write and prototype this code right away, no need to wait for Wayland deployment). Of course, X remoting existing today means that we'll be probably be using it until it's taken away from us...

There's some irony here...

Posted Feb 14, 2012 11:33 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Hm, that's true, the toolkit can easily remember all this stuff, including enough to implement a lot of useful optimizations. There are still more than two toolkits, but only two seem to have been written with any expectation of multiple-backend support, so, yes, remoting support in Gtk and Qt is probably sufficient.

Of course this means duplicating security-critical networking and authentication code twice, rather than having it centralized in one place. (One place which still needs to run as root! Why? I thought the X-as-root thing was on the verge of solution, or is everyone running chasing Wayland now too hard to fix this security weal on the side of Unix?)

There's some irony here...

Posted Feb 14, 2012 16:00 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

I'm sure I'm missing something, but why do you need to duplicate the security-critical authentication code? I would expect something more along the lines of "remote application spawns SSH process that tunnels the toolkit-specific protocol to the machine running the Wayland compositor, where a serialised-GDK Wayland client is started just for this app", where SSH handles the authentication for you, and the GDK Wayland client runs under your credentials.

There's some irony here...

Posted Feb 14, 2012 23:06 UTC (Tue) by nix (subscriber, #2304) [Link]

Yeah, that would work, I suppose. SSH tunnelling is cheap enough now that I only notice it when I'm trying to tunnel full-motion video across it (*that* is likely to always be too slow to be useful, since CPUs are getting no faster and most crypto algorithms are not terribly parallelizable).

There's some irony here...

Posted Feb 14, 2012 13:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

>CPU reading from GPU memory is very slow.
It's not THAT slow. It's certainly possible to read GPU surfaces 5-10 times each second (more than enough for remoting) without noticeable load.

There's some irony here...

Posted Feb 14, 2012 18:49 UTC (Tue) by wmf (guest, #33791) [Link] (4 responses)

Since the window is in GPU memory already, it may be possible to use the GPU to diff/compress it instead of the CPU. For example, to detect scrolling you'd use well-studied motion estimation algorithms.

There's some irony here...

Posted Feb 14, 2012 23:41 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

Aren't most motion estimation algorithms really rather CPU-expensive? I thought Wayland was meant to be more efficient than X, not orders of magnitude less.

There's some irony here...

Posted Feb 15, 2012 5:59 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

I think it belongs to make the simple things simple and hard things possible. X fails horribly at that: local access requires a lot of useless dances. Wayland improves situation a lot of a common case, but yes, it makes rare cases more expensive.

There's some irony here...

Posted Feb 15, 2012 15:44 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Rare cases like 'scrolling the screen'. Sorry, not a rare case unless you define all remote access as 'rare', in which case I'd like to point out this virtualization and 'cloud' stuff that is all the rage these days.

There's some irony here...

Posted Feb 15, 2012 19:20 UTC (Wed) by alankila (guest, #47141) [Link]

The toolkit protocol must support efficient scrolling. If it can for instance just send the textarea's text content over the wire and leave it all to local client then great, problem solved.

If it's something more complex like images that don't even exist until they get inside the viewport, then of course local client must send request for updated image pixmap and then that must get generated and sent, but still scrolling for the part that is already known locally should be possible.

I think it's vital that in a good design we avoid the "let's treat app as black box and send data like it was full motion video"... It's great if it's an option for some dummy app/toolkit that can't do this (some types of games?) but for, say, GTK+ app I'm convinced that much better solution exists.

There's some irony here...

Posted Feb 14, 2012 0:59 UTC (Tue) by jmalcolm (guest, #8876) [Link]

I have not dug into the guts of Wayland but is this a fair comparison?

The Windows on my desktop, including the one I am typing in now, change very little. I would say that 95%+ of my browser window has not changed in the last twenty seconds even though I have been actively typing (and I am a pretty fast typist).

The bandwidth requirements to stream a video of my browser window would be immense a the quality and frame rate that I expect. I would assume that Wayland would simply provide snapshots of the pixels (or regions of pixels) that have actually changed and only when they change.

If I type at sixty words per minute, a refresh rate of one Hertz (or twice that to be safe) would be sufficient to keep up. I am sure though that the screen is actually refreshing at sixty Hertz or faster even on my shitty laptop.

Now, if I was playing a full-screen, rapid motion, OpenGT game or something then the video codec comparison might be fairer. Then again, what video codec can do real-time compression and decompression where frames are not guaranteed to be substantially similar? In this extreme case, just sending "snapshots" of each image seems like not too bad an option. The "snapshot" images can certainly be compressed as well of course.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 3:01 UTC (Tue) by hechacker1 (guest, #82466) [Link] (81 responses)

I'm curious; to all those people that say X11's network features are useful, can you show me examples of what you do with it?

I know it works decently over a fast pipe with a low rtt, but so does RDP or VNC.

But when on the internet, I think I've only used this feature maybe once or twice, ever. I loaded firefox remotely and started a download. It was slow as molasses. But it worked. I also started a torrent remotely.

In either case, I probably would have had better performance with VNC.

So for me, I just don't see the practical application of being able to stream applications in the X11 protocol when it doesn't feel any faster than the simple screen grab VNC solution. In fact, VNC with lots of compression, and low bitrates, is faster.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 3:12 UTC (Tue) by dlang (guest, #313) [Link] (6 responses)

well, especially if you cannot do multiple desktops with Wayland, something like Maddog's latest project (Project Caua http://www.projectcaua.org/ video of his presentation at LISA in December http://www.youtube.com/user/USENIXAssociation#p/u/44/LlNa... ) is not going to be possible, while it's fairly straightforward with X

This is a powerful server connected via fast, low-latency lines to slow/cheap thin terminals. Exactly the type of thing that X was initially designed for.

It would be sad to see developers move to GUI toolkits that can't talk X "because nobody has used the X network transparency in a decade"

Wayland - Beyond X (The H)

Posted Feb 14, 2012 3:25 UTC (Tue) by Kit (guest, #55925) [Link] (5 responses)

> well, especially if you cannot do multiple desktops with Wayland

I've not seen anything that would say you can't do multiple desktops with Wayland, so what are you basing that on? Is there a limitation with the current video card drivers?

> This is a powerful server connected via fast, low-latency lines to
> slow/cheap thin terminals.
Precluding the "cannot do multiple desktops" thing said before, wouldn't Wayland work better in this situation? Wayland would mean the terminals aren't doing much more than just bliting images to the screen, something even very cheap, low end ARM devices can do no problem.

I'm also not really convinced we'll see a rise of thin clients. Phones and Tablets are seeing rapid advancements in both CPU and GPU performance, and generally have a fairly respectable amount of memory (even the Kindle Fire has 512 MB RAM). Compared to the cost of the screen, I don't really see too much potential saving by going with even lower end processors than ARMs (the Raspberry Pi can easily drive a display at a fairly high resolution, and it certainly doesn't have very impressive specs compared to the high end SoCs).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 3:43 UTC (Tue) by dlang (guest, #313) [Link] (4 responses)

it was another poster who said that the number of apps was a problem

the thing is that something like the raspberry pi can do simple blitting of images to the screen, but it also has enough power to do smarter things. It would be quite a waste to have to just use blitting and not be able to do anything smarter. In something like project Caua this extra bandwidth needed could start to bottleneck the server network I/O and it's switch uplink port. On the other hand, something like the raspberry pi won't have the memory to store lots of images itself and do the compositing locally.

I'm not saying that something smart can't be done. Quite the opposite. I'm saying that if they just wait to figure out how to remote it later it's not going to be easy (if it's at all possible) to retrofit the design to support it.

Even if the support is as primitive as 'damage' effects and rectangle movement, it should be designed in rather than planning to have something else figure it out from the resulting output.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 9:52 UTC (Tue) by epa (subscriber, #39769) [Link]

Even if the support is as primitive as 'damage' effects and rectangle movement, it should be designed in rather than planning to have something else figure it out from the resulting output.

Reminds me a bit of the debate about file renames in version control. You can add an explicit rename operation, or like git you can just track name=content pairs and figure out rename operations afterwards.

I think that nowadays it may make sense to burn a lot of CPU power on the sending end, boiling down and compressing changes to the screen buffer, so that you cut down bandwidth use. This is what many popular remoting protocols do anyway (and raw X11 protocol is not really usable over the wider Internet).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:04 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

You really should read the Wayland protocol description before commenting on what needs to be in there. The sum total support for rendering in Wayland 0.85 is:

A mechanism to set up a shared buffer between the compositor and the client.
A mechanism to tie the contents of that shared buffer to an on-screen surface, possibly offset from the origin of the surface.
A mechanism to indicate to the compositor that a region of the shared buffer backing a surface has changed contents, and that the compositor should update the surface as presented to the user.
A mechanism for the compositor to use to tell the client that a new frame has been presented to the user, and thus it's worth creating new content.

Nothing in that precludes efficient remote operation - indeed, the damage events and buffer to surface attachment make a VNC-like protocol very easy to implement for any arbitrary Wayland client, including efficient support for scrolling.

The current plan, as laid out by the Wayland developers, though, is to expect the higher level toolkits (GTK+, Qt etc) to handle efficient remoting; they have much more detailed semantic views of what the user is trying to achieve, and (in theory at least) can do a much better job of minimising data transferred without compromising user experience.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:34 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

A VNC-like protocol is hopeless as soon as you encounter unusual rare and difficult operations like scrolling a surface. Oops, that's a massive damaged region and a massive bitmap copy.

A remote protocol in which you cannot scroll an xterm or a GIMP window at >5 refreshes/sec is essentially useless (that's what I see with VNC on a GbE LAN).

So remoting will clearly have to be done in the toolkits. Which means that toolkits that don't bother to implement their own remoting protocol will suddenly not be network-transparent anymore if you are using a Wayland server.

Joy.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 13:41 UTC (Wed) by farnz (subscriber, #17727) [Link]

Practically, I expect the following to happen if network transparency matters enough for people to put forward money (e.g. Red Hat telling its employees to make it happen for Red Hat's VDI product) or code (e.g. a lone developer who cares enough to work on it):

There will be a bridge client for Wayland that supports X11 protocol. Any toolkit that can efficiently remote over X11 will use this bridge at first.
The major toolkits (Qt, GTK+) will be ported to have an optional Wayland backend for local use only.
The major toolkits will acquire private remoting protocols that are optimized for their particular rendering usage, creating two competing NeWS-like systems, where the backends for the remoting protocols are written in the same languages used for the toolkits.
Some bright spark will spot that the private remoting protocols are fairly similar, and come up with a unified remoting protocol for both major toolkits, possibly even something NeWS-like but with a saner language for the server side widgetry.
Minor toolkits will pick up this remoting protocol as it's fairly simple to do so, and it satisfies the need for remote clients.

There's also a second plausible route for getting a network-transparent Wayland going:

Wayland clients adopt EGL en-masse as their accelerated local rendering API. Wayland clients either have no acceleration (they treat the display server as providing a dumb framebuffer, so no display server can remote them efficiently), or they use OpenGL and EGL to render.
Someone produces a virtual GPU intended for the VM situation, where GPU commands are serialised in and out of the VM, and implements a Mesa driver for it.
Someone adapts that virtual GPU, so that the serialisation protocol works well over a network.
The obvious combination of networked virtual GPU and Wayland protocol is defined for running over a network connection.

This second route has one advantage; there are multiple groups who would like an efficient virtual GPU, and so there's likely to be more manpower available for it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 4:30 UTC (Tue) by daglwn (guest, #65432) [Link] (4 responses)

> I'm curious; to all those people that say X11's network features are
> useful, can you show me examples of what you do with it?

Running any software that is not built for Linux, requires access to a license server behind a firewall or otherwise uses resources I don't have everywhere.

> I know it works decently over a fast pipe with a low rtt, but so does
> RDP or VNC.

IME both RDP and VNC are much slower than remote X. That's maybe because commercial applications tend to have less eye candy than the typical Linux program.

Then there's the problem of convincing your workplace to open up RDP and VNC across the firewall.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 7:53 UTC (Tue) by niner (guest, #26151) [Link] (1 responses)

> Then there's the problem of convincing your workplace to open up RDP and VNC across the firewall.

But you don't have to. Both can be tunneled just fine over ssh just like X

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:38 UTC (Tue) by daglwn (guest, #65432) [Link]

Ah, I didn't realize that. Thanks for enlightening me.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 9:24 UTC (Tue) by daniels (subscriber, #16193) [Link] (1 responses)

Running any software that is not built for Linux [...]

Wayland only runs on Linux, so I think it's safe to say this software won't ever be ported to Wayland. Happily for you though, you can already nest X and Wayland sessions infinitely deep within each other, so you can have a remote X app displaying in your Wayland session, right now, today.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 16:25 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

It will be ported. You just need to wait two RHEL cycles (first one for proprietary vendors to notice something changed and second one to do something about it)

Of course given on how RHEL cycles have become longer with time, it can take at least a decade for this

Wayland - Beyond X (The H)

Posted Feb 14, 2012 6:29 UTC (Tue) by JohnMorris (guest, #73531) [Link]

> I'm curious; to all those people that say X11's network features are useful, can you show me examples of what you do with it?

In our work development environment we have a reasonably good Linux server. But by company policy our desktop machines are all Windows. Different developers choose to work in different ways, but I use a Windows X over ssh implementation to access the server. 99% is editing and building. It works, and has kept me productive for many years.

> I know it works decently over a fast pipe with a low rtt, but so does RDP or VNC.

Your points are well taken, and I do use VNC at home. The issue I have with it for work use is that it gives me a full screen grab. I don't want that - I just want some windows on my screen that are attached to processes on the remote, sharing my desktop space with other, local windows, so I can have email (Outlook running on local Windows) and an editor (running on the server) and a command line (also on the server) all visible at the same time.

I would be sad to lose that ability.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:39 UTC (Tue) by nix (subscriber, #2304) [Link]

X is intolerably slow over pipes with high RTT. However, over pipes with lower RTT, VNC is intolerably inefficient: even SPICE is nasty. I can't run more than two full-screen SPICE sessions at once over my gigabit Ethernet here because the network starts colliding and my CPU fans all spin up from handling the tens of Mb/s transferred between machines: all the sessions turn into molasses. VNC is much much worse. Meanwhile, the overhead from a dozen full-screen X sessions? I can't even see it: a few packets per second, no more.

Full dumb bitmap transfer a-la VNC is perhaps tolerable as an emergency fallback for one or two applications. It is not sustainable if you want to run several routinely. (Obviously, if you are running several routinely it is unlikely they will be filled with animated full-motion video. Optimize for the common case here: things that are relatively static when the user is not interacting with them, and especially textual output. You can't say textual output has got any less common!)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 11:39 UTC (Tue) by robert_s (subscriber, #42402) [Link] (3 responses)

"I'm curious; to all those people that say X11's network features are useful, can you show me examples of what you do with it?"

I have a bunch of development machines here and I got bored a while ago with messing with KVM switches & the like. These days I simply ssh -X into these other machines and when I need to run a graphical app, I just start it as though it's on my local machine and the windows are right there on my desktop as though nothing's different.

I've been pleasantly surprised with X's remote performance.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 16:34 UTC (Tue) by marduk (subscriber, #3831) [Link] (2 responses)

I'll bite. I have a project where I create a few tiny kvm-based virtual machines. These are all headless virtual machines, some run such desktop environments as GNOME, KDE, and XFCE. Right now I can connect to them from the host environemnt (or any environment for that matter) using XDMCP or SSH with X11 forwarding, and don't require an X server to run or even be installed on the virtual machines. This works nicely using minimal resources (e.g. only ~150MB RAM used to run full KDE).

Granted, this is not a "typical" scenario for a typical desktop user, but it is one of the things I'd really miss if I didn't have it in Wayland.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

You'll still need all the client-side GTK/QT/KDE infrastructure, even with X.

And you certainly wouldn't need to run the full KDE/GNOME environment with future-Wayland-remoting. From your point of view nothing is going to change.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:36 UTC (Wed) by wahern (subscriber, #37304) [Link]

The client side stuff is fine. It's the privileged rendering pieces (setuid this, kernel modules that) which are root kit fodder and that I'd never put on a network accessible server. Security--least privilege, safe and prudent memory manipulation, etc--is the last thing the guy writing OpenGL optimizations is thinking about.

It's the same reason WebGL is becoming exploit city.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 12:47 UTC (Tue) by Berend (guest, #82898) [Link] (1 responses)

"I'm curious; to all those people that say X11's network features are useful, can you show me examples of what you do with it?"

* Run GUI apps that need specific hardware (not all hardware is keyboard, mouse and screen)
* QA
* Proxied and tunnelled sessions.

Could I do a lot or all of these things using VNC? Probably yes. As efficiently? Nope.

The biggest downfall of VNC for remote system access to me is on multi-user systems. VNC just falls flat on it's face.

Why is it so hard to believe that there are valid use cases for remote X?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:09 UTC (Tue) by nix (subscriber, #2304) [Link]

Among other things, the 'big server running lots of stuff including some graphical stuff' and 'smaller desktop' model is *not* yet dead (particularly if the 'big server' is always-on and the desktops are not: power is getting more expensive, not less...)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 13:54 UTC (Tue) by teknohog (guest, #70891) [Link] (12 responses)

> I'm curious; to all those people that say X11's network features are useful, can you show me examples of what you do with it?

I used to do physics and chemistry modelling, using software that runs on a supercomputer. This involved manipulating OpenGL graphics, though I never got into really complex scenes. Sometimes I worked from home over ADSL or cable, and it was not much different from work.

I think the important difference to VNC was that most graphics were rendered on my laptop, only rendering commands went over the network. People talk about intelligent caching and compression in other protocols, but it seems backwards to me -- first render the scene, then compress it back into some simpler commands, then render (uncompress) it again.

Of course, sometimes the graphics themselves need supercomputing power to be rendered. Or you need some other, specific features of that remote GPU.

IMHO, one issue with this debate is that VNC works basically in all cases, though not necessarily well. X fails in some cases, but in others it is much better than VNC. So it is a question of right tool for the right job, or one size fits all.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 14:33 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (11 responses)

Any sensible remoting protocol probably does want to provide a useful mechanism for pushing 3D primitives over the wire, but X isn't it. GLX tops out at OpenGL 1.4.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:11 UTC (Tue) by nix (subscriber, #2304) [Link] (10 responses)

And the obvious solution to this is to reimplement absolutely everything, rather than figuring out a serialization protocol for the parts of OpenGL => 1.4.

Bah. CADT syndrome *again*. I'm really sick of it.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

NVidia has proprietary implementation in their drivers. Doesn't really help a lot, because modern OpenGL is even _more_ chatty and bandwidth-intensive than X.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 13:58 UTC (Fri) by man_ls (guest, #15091) [Link] (8 responses)

Excuse my asking, but what is CADT syndrome? Google takes me directly to... your comment.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 14:12 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (7 responses)

http://www.jwz.org/doc/cadt.html

Cascade of Attention-Deficit Teenagers for the next unfortunate googler

Posted Feb 17, 2012 14:22 UTC (Fri) by man_ls (guest, #15091) [Link] (6 responses)

Thanks! Given that the explicit goal of Wayland is to salvage the good parts of X11, and that this particular system (X Window) has apparently not been rewritten since 1987, in this case a start from scratch might very well be excused (or even in order).

Keep in mind that people who were born the year that X11 was released are now 24 years old, hardly teenagers any more! Giving the new product a new name is something that we should be grateful for.

Cascade of Attention-Deficit Teenagers for the next unfortunate googler

Posted Feb 17, 2012 15:27 UTC (Fri) by renox (guest, #23785) [Link] (5 responses)

> X11 was released are now 24 years old

Focusing on the age of the first release is a CADT syndrome..

Cascade of Attention-Deficit Teenagers

Posted Feb 17, 2012 16:22 UTC (Fri) by man_ls (guest, #15091) [Link] (4 responses)

Ah, these kids... 1988 was the year of the latest version, X11, not the first. Its history started around 1981, or so the Wikipedia article states. If you prefer to refer to the latest revision X11R7, then it's only 7 years old... and on that memorable event X11 gained the ability to use ravaging new autotools (a project started in 1991).

Look at it as you may, X is probably the oldest component in use on our systems, except perhaps if you are an Emacs user. I don't know anything about the X codebase except that it is scary and that its creators (not exactly teenagers) seem to loathe it. And now I will link the mandatory Xkcd comic and will leave this humongous article (404 comments at this time) alone.

Cascade of Attention-Deficit Teenagers

Posted Feb 17, 2012 17:24 UTC (Fri) by renox (guest, #23785) [Link] (3 responses)

>Look at it as you may, X is probably the oldest component in use on our systems, except perhaps if you are an Emacs user

Your point being?
Even if I don't use Emacs, I know that it's very powerful and that it has many satisfied users, which show nicely my point: age doesn't really matter when you're talking about software.
And Linux isn't young too..

You know the reason of the comic you linked?
The fact that now the X server is able to work correctly most of the time without the user having to touch its configuration file, whoa X progressed! Incredible!

>I don't know anything about the X codebase except that it is scary and that its creators (not exactly teenagers) seem to loathe it.

LibreOffice has/had exactly the same issue, but they're cleaning their codebase, of course they have many more developers than X.

Cascade of Attention-Deficit Teenagers

Posted Feb 18, 2012 3:56 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

>Even if I don't use Emacs, I know that it's very powerful and that it has many satisfied users, which show nicely my point: age doesn't really matter when you're talking about software.
Does it? The number of emacs' users is utterly dwarfed by the number of Microsoft Visual Studio users or Eclipse users.

And can we honestly say that emacs is really better? I don't think so.

>You know the reason of the comic you linked?
>The fact that now the X server is able to work correctly most of the time without the user having to touch its configuration file, whoa X progressed! Incredible!
Actually, it is. Few more years and popular toolkits on Linux desktops might start to use XInput2 in earnest.

>LibreOffice has/had exactly the same issue, but they're cleaning their codebase, of course they have many more developers than X.

They don't operate under the same constraints.

Cascade of Attention-Deficit Teenagers

Posted Mar 1, 2012 14:10 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Ah yes. Because the utility of software is perfectly expressed by a popularity contest. Windows is objectively better than Linux by that metric, and various obscure embedded OSes are even better! Look at the number of units shipped!

Software can have different target markets. Someone satisfied with Visual C++'s editor is unlikely to need or want the flexibility of Emacs: someone whose mind is written in Lisp and who dreams in Emacs keybindings is never going to be satisfied with Visual C++. (I wish the 'dreams in Emacs keybindings' part was a joke, but I got out of an allergy-induced nightmare last night by hitting C-g to wake me up. It worked.)

Cascade of Attention-Deficit Teenagers

Posted Mar 1, 2012 15:48 UTC (Thu) by khim (subscriber, #9252) [Link]

Because the utility of software is perfectly expressed by a popularity contest.

Well… yeah. What else can you suggest?

Windows is objectively better than Linux by that metric, and various obscure embedded OSes are even better!

Windows is most definitely better, but various obscure embedded OSes are not: they are not in the same market. In some cases embedded Linux does better then other embedded OSes (smartphones, for example), in some case it's worse (featurephones, for example), but on desktop it's so far behind it's not even funny.

Software can have different target markets.

Ah-ha. So you do get it. You just refuse to admit defeat.

Someone satisfied with Visual C++'s editor is unlikely to need or want the flexibility of Emacs: someone whose mind is written in Lisp and who dreams in Emacs keybindings is never going to be satisfied with Visual C++.

Sorry, but no. For that to happen someone must first be exposed to Lisp. People whose mind is written in Lisp are not numerous enough to form a genuine separate market. If you'll take a look on the “new generation”, you'll find out that a lot of them used Visual C++ at one point or another, but most have never ever tried to use Emacs. For them it may not even exist.

This means that when “old generation” will go away (which is kind of inevitable) Emacs will be just a footnote in a Wikipedia.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 15:26 UTC (Tue) by daglwn (guest, #65432) [Link] (44 responses)

Here's another one. Debugging HPC applications. The supercomputer does not have a screen or a keyboard or a mouse. Access thought a remote terminal is the only option. A debugging GUI has to run on the supercomputer but be displayed on the terminal.

And good luck getting RDP or VNC installed on a supercomputer.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:27 UTC (Tue) by khim (subscriber, #9252) [Link] (39 responses)

Why? It's not needed with GDB, why it's requirement for your debugger?

Everyone here looks obsessed with "inefficient" handling of text (and such) in Wayland. But can you, please, answer why you need to run all these programs on your remote system? Why can't you use some application-specific protocol to communicate with server component?

It'll be more efficient then any GUI remote access protocol.

I think I know the answer: today you get what you need for free. The fact that X is inefficient in local case (direct-to-GPU rendering is obviously more efficient then what you do with Xlib today), it's inefficient for remote case (application-specific protocol will be obviously more efficient), but you get what you want for free. Everyone else is paying. Why do you think it's fair? If you need remote access then you need to pay for it - it's as simple as that. You can pay for developers and ask them to add remote protocol, or you can pay with your time add it yourself, but the idea that everyone else must suffer for your sake is just ridiculous.

I, for one, don't use VNX, X networking, or anything like that, but I use plenty of remote protocols (like aforementioned remote GDB capabilities). SSH is enough to start what I need (especially if you combine it with screen or tmux) and that's it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:31 UTC (Tue) by dlang (guest, #313) [Link] (36 responses)

today the GUI toolkit writers have to implement their toolkit in a way that supports network transparency, but the application programmers using the toolkit don't have to care.

If the application programmers all have to modify their software to implement client-server versions it's just not going to happen for the vast majority of applications.

so doing away with the network transparency from the mindset of the application programmer is a significant regression for many people.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:40 UTC (Tue) by khim (subscriber, #9252) [Link] (35 responses)

today the GUI toolkit writers have to implement their toolkit in a way that supports network transparency, but the application programmers using the toolkit don't have to care.

If that's true then perhaps the proper level where network transparency should be implemented is the GUI toolkit.

But I doubt it. It's pretty easy to implement GUI using approach which is fast and simple on local system but slow and inefficient over the network.

It's not new situation: if you compare NC/FAR with MC you'll see that MC sucks. Because it must support "old terminal" paradigm where NC just redraws the whole screen every time you press the button.

Similarly Photoshop just redraws the whole screen 10 times per second if you select objects. Works fast even on very old GPU but completely unusable over less then 1GnE network.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:29 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (34 responses)

I'm guessing "MC" is midnight commander (though possibly not due to it being a GUI thread), but what is "NC/FAR"?

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:55 UTC (Tue) by khim (subscriber, #9252) [Link] (33 responses)

I'm guessing "MC" is midnight commander, but what is "NC/FAR"?

MC is indeed Midnight Commanded, NC is it's prototype (Norton Commander), FAR is Windows equivalent.

The fact is: MC has very poor and buggy imitation of NC/FAR TUI - exactly because it's forced to support "network transparency". But this is more-or-less Ok since a lot of people who use MC at all use it over ssh. But it shows that "network transparency" creates serious problems even for text interface. And to say that you get network transparency for free in X is just wrong. Better to say that all the users and all the developers are forced to pay for the feature which is used by a tiny minority.

Said tiny minority is extremely vocal but I don't see why it's needs must trump the needs of everyone else.

though possibly not due to it being a GUI thread

It's relevant because NC/FAR implement Wayland model (where text console is just a buffer where program can stuff characters with attributes) and MC implements "network-transparent" model (where text goes to "terminal sever" which interprets escape sequences). What is simple, basically trivial in NC/FAR (things like Ctrl-O) is buggy and unreliable in MC. But yes, you get a network transparency instead. Situation with Wayland and X is exactly the same with one small difference: few people care about network transparency in this case.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:31 UTC (Tue) by nix (subscriber, #2304) [Link] (32 responses)

Hang on. You're claiming now that *ncurses programs* cannot be efficiently transported over the network?!

Your comments are pretty clearly detached from reality at this point.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:38 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (31 responses)

No, the problem is in the network transparency, MC has to work with a server which interprets bytecode for text UI rendering. Even though this server is crufty and has very poor state tracking.

That shows a lot - MC can't recover from a lot of situations that leave console in a 'bad' state so Ctrl-O is completely unreliable.

FAR simply works with a _reliable_ text buffer. FAR can always be sure that whatever it writes to the console buffer is going to be shown correctly. It behaves almost exactly like the video RAM in old computers - you write a pixel to a memory location and it is shown immediately on the screen.

One can somewhat imitate this behavior on Unix ttys by sending the whole screen content after each change but even that is not completely foolproof.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:43 UTC (Wed) by dlang (guest, #313) [Link] (30 responses)

why do other text based programs not have this problem when being run remotely?

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:46 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (29 responses)

They have, but not as dire.

For example, I can get corruptions in text-based Debian or RedHat/CentOS installers easily. You don't need for them to run remotely, btw. "Network transparency" of the console ensures that they are just as buggy locally.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:48 UTC (Wed) by dlang (guest, #313) [Link] (28 responses)

what are you referring to as a "corruption"?

Wayland - Beyond X (The H)

Posted Feb 15, 2012 0:53 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (27 responses)

Things like leftovers from a previous program on solid background of a ncurses program, incorrect position of cursor in an input field, ^H instead of actual <backspace>, etc.

A lot of these are simple annoyances, but they're there.

Please, don't tell me that all text-based UIs work without problems for you. I simply won't believe you.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:03 UTC (Wed) by dlang (guest, #313) [Link] (26 responses)

I would question how many of these are due to any network transparency vs how many are due to buggy terminal emulators.

I've seen the exact same types of problems on local consoles, no X or network transparency in sight.

I think you're blaming the wrong component for the problem

Wayland - Beyond X (The H)

Posted Feb 15, 2012 2:50 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (12 responses)

It's not that the terminal emulators are buggy, though I'm sure some of them are. It also has nothing to do with network transparency, which should be obvious given that very few other network-transparent protocols share these particular flaws.

The problem stems from the fact that multiple terminal clients share a single serialized connection to the terminal (real or emulated), with quite a bit of shared state and little or no inter-client coordination. To solve it you would need to ensure that separate clients have their own state and can't interfere with other clients' connections to the terminal--just as each X client has its own independent connection to the X server.

Windows-style terminals have similar issues when multiple programs try to control the same terminal window in conflicting ways (e.g. if one program attempts to scroll the buffer while another is drawing position-dependent widgets). They just don't share nearly as much state, mostly due to their extremely limited feature set. They are also much more likely to be restricted to a single program at a time, background processes being practically non-existent in the Windows command-line environment.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 5:54 UTC (Wed) by khim (subscriber, #9252) [Link] (11 responses)

It also has nothing to do with network transparency, which should be obvious given that very few other network-transparent protocols share these particular flaws.

Very few network-transparent protocols are used to mix and match unrelated programs. You can not just shove some graph-plotting program in your GNOME or KDE panel. You need specialized programs which used specialized interfaces for that.

It's trivial and efficient to do that with Wayland. Is it useful for all the programs out there? Probably not (even in console world you only have limited number of programs which do that). But for some of them it's real big plus.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 16:11 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (10 responses)

Not that I disagree with anything you just said--but how does it relate to the quote you were replying to? Were you perhaps implying that the problems dlang was erroneously attributing to network transparency are instead inherent to network-transparent "protocols ... used to mix and match unrelated programs"? I don't see any basis for that assertion, either.

I have no problem with Wayland or its shared-memory architecture as a purely *local* means of compositing GUIs onto a real or virtual desktop. As I understand it, that is what Wayland was designed for, so there should be no argument there. Network transparency should be implemented at the rendering layer, and as has been stated repeatedly, Wayland does not define a rendering API. Personally, I envision something like a serialized implementation of the Gallium3D APIs taking the place of AIGLX for hardware-accelerated remote rendering, with individual applications being none the wiser. (Naturally, this would work best if they don't assume zero latency and infinite bandwidth between the CPU and GPU, but those are factors in the local case as well.)

The main concern, apparently shared by many others, is the applications may come to take Wayland's low-latency shared-memory design for granted, limiting remote access to slow, inefficient video streams--but we face that problem with X clients already.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 16:35 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (9 responses)

> the problems dlang was erroneously attributing to network transparency

Sorry, but that should be Cyberax, not dlang. It seems I got the positions backward... Anyway, the point is the same. These problems aren't because the terminal protocol is serialized (network transparent), but rather because all interaction with the terminal is squashed into a single uncoordinated stream. And complaining about _input processing_ compatibility issues such as backspace appearing as ^H is just silly; the same thing happens on Windows terminals if you press unrecognized control sequences. The only difference there is that Windows only has one terminal type, which always defines backspace as ^H; Unix, with its richer history, is designed to be interoperable with many different terminal protocols.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 21:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>Sorry, but that should be Cyberax, not dlang. It seems I got the positions backward... Anyway, the point is the same. These problems aren't because the terminal protocol is serialized (network transparent), but rather because all interaction with the terminal is squashed into a single uncoordinated stream.

Yes, it's certainly possible to design a good "remote rendering" protocol for something as simple as text. Yet it hasn't been done, and we all suffer because of it.

And the analogy with X11 is direct - Unix terminals are outgrowths of real wired terminals and so they had the "network transparency" from the start causing them a lot of problems.

>And complaining about _input processing_ compatibility issues such as backspace appearing as ^H is just silly; the same thing happens on Windows terminals if you press unrecognized control sequences.
Wrong. Windows console layer knows _nothing_ about control characters, it provides a "video surface" to applications on which they can do whatever they please.

Serial console emulators working on top of the console layer, of course, can (and do) misbehave.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 21:37 UTC (Wed) by khim (subscriber, #9252) [Link] (7 responses)

These problems aren't because the terminal protocol is serialized (network transparent), but rather because all interaction with the terminal is squashed into a single uncoordinated stream.

It's coordinated. You have escape sequences and about bazillion libraries which try to generate/interpret/parse them. The whole mess includes about ten thousand times more code (no, I'm not joking!) then simple buffer-to-buffer memcpy approach which worked perfectly fine on all computers starting from tiny ones like MSX (which had something like 32KB of RAM thus it quite literally had no power to even try to cope with all these libraries).

If you never used MSX then recall MS DOS. Things like Sidekick worked just fine there and newer created mess on screen. And the same is true on OS/2 and Windows.

And complaining about _input processing_ compatibility issues such as backspace appearing as ^H is just silly; the same thing happens on Windows terminals if you press unrecognized control sequences.

Only if program decides to show it explicitly. On Linux because of network transparency layer you get mess on your screen when you combine TUI programs in non-trivial form. You can only be sure that everything will work fine if you use simple programs which don't try to format output. Things like “"ls --color=auto” are not needed on DOS/Windows/etc terminal (they are needed if you want to store output in a text file and then process it as a text file, not as a terminal buffer, but that's different story).

The only difference there is that Windows only has one terminal type, which always defines backspace as ^H; Unix, with its richer history, is designed to be interoperable with many different terminal protocols.

Nope. That's because you don't need complex and convoluted logic to process data. If key comes to your program then it's Key Event or Mouse Event. If you write text on the screen then you write it on screen.

Easy, simple, reliable. Not flexible, that's for sure (it's not easy to get “screen output” of one program and interpret it as “keyboard input” for another program). Basically in DOS/Windows/etc you have solution which solvers perfectly most popular cases and is almost totally useless for less common cases while in *nix you have solution which does everything... poorly.

Wayland vs X is the same story: you can use Wayland to do things which are very easy, simple and power-efficient (things like complex scrolling effects which are demanded by Joe Average who've seen iOS or Android) but other things (like network transparency) are hard to implement (if they are possible at all).

What will you prefer? It depends on what you want to do, really.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:08 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (6 responses)

Seriously, we get it--though I'm not sure you do. You hate escape sequences and think it makes more sense to give TUI program direct low-level access to the terminal--write this string at this location in this style, poll for input events, etc.

Well, perhaps that does make more sense, at least for TUI applications. (For normal command-line programs its obviously a step backward, since there is no easy way to recover the original text once it's been formatted into a terminal buffer.) However, it could be done with a trivial network-transparent protocol just as easily as with a shared memory buffer. The important point is having low-level access to a very thin terminal, not how you communicate with it. Shared memory is faster due to being zero-copy (though not necessarily by a large margin), while message-passing has fewer locking issues and works better when latency is high. You can always convert one form into the other, though going from shared memory to message-passing tends to much less efficient since the original structure is not preserved.

P.S. TUIs are almost entirely an anachronism by this point. The systems which make regular use of text terminals use them mainly for CLIs, not TUIs, and many of these CLI programs are designed for serialized I/O. If you want low-level access, including direct access to the screen and input events, write a GUI. It really doesn't make sense to design applications around raw VGA-style text buffers only to run them in a terminal emulator running inside X.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:17 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

by the way, you can run into similar formatting problems with direct screen access if you make the mistake of outputting a character to the bottom right of the screen and let the screen scroll on you.

if you just do direct I/O to the screen, character by character you don't have this problem, but you can run into the problem that a badly written program starts scribbling on whatever is in memory right after the screen.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:25 UTC (Wed) by khim (subscriber, #9252) [Link]

by the way, you can run into similar formatting problems with direct screen access if you make the mistake of outputting a character to the bottom right of the screen and let the screen scroll on you.

How? Direct screen access just puts your character there? To scroll the buffer you need completely another function.

if you just do direct I/O to the screen, character by character you don't have this problem, but you can run into the problem that a badly written program starts scribbling on whatever is in memory right after the screen.

You have this problem in any protocol with shared memory. That's what memory protection is for :-)

Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:32 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

Seriously, we get it--though I'm not sure you do.

I'm not sure you get my point.

You hate escape sequences and think it makes more sense to give TUI program direct low-level access to the terminal--write this string at this location in this style, poll for input events, etc.

Not just for TUI. GUI, too.

However, it could be done with a trivial network-transparent protocol just as easily as with a shared memory buffer.

This is not proven. Most network-transparent protocols lead for the mess both in TUI and GUI case. My point is: if we can not even handle simple case (TUI) then what hope is there for more complex case (GUI)? If TUI suffers from the introduction of “effective network-transparency layer” then why don't you expect the similar effect on GUI? And if said transparency layer is actually damaging then are we even sure it's good idea to make it non-optional component?

Wayland - Beyond X (The H)

Posted Feb 15, 2012 23:16 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (2 responses)

> Not just for TUI. GUI, too. ... Most network-transparent protocols lead for the mess both in TUI and GUI case.

I'm not seeing that at all. Your examples all come from the legacy serial terminal and its escape codes, and do not apply to GUIs. Elsewhere you did state that "When you see garbage in your console and when you see overlapping text in your [remotely served] Firefox it's the exact same failure", but (a) I've never seen that kind of failure, and (b) even presuming it exists, it doesn't really seem like the same thing at all.

> If TUI suffers from the introduction of “effective network-transparency layer” ...

But it doesn't. TUI suffers from being forced to work through a protocol which was not "designed" so much as "evolved", in the very early stages of computer science, before we learned to design proper protocols, constantly merging features from similar-but-incompatible protocols and being extended and forked for various special cases. The implementation *is* the standard, and yet there is no single reference implementation. Given all of that, it's something of a wonder that it works at all.

I doubt a direct-access protocol would work as well--consider trying to write such a TUI when there is no standard memory layout, color/style encoding, character encoding, input API, etc. That interface is simpler only because it is standardized. If you ignored the issue of legacy compatibility, and simply defined what you want the terminal to do (perhaps based on the Windows terminal API), you can trivially provide a well-defined way to serialize those commands into a stream of messages which will achieve the same effect without any of the problems you've described.

> ... if we can not even handle simple case (TUI) then what hope is there for more complex case (GUI)? ... why don't you expect the similar effect on GUI?

Basically, because the GUI case (both for X11, and even more so for whatever remoting protocol is used with Wayland) is not nearly so encumbered by the need to remain compatible with legacy clients. There are actual independent standards involved. X11 has some legacy clients to deal with, but the original protocol was still much better defined than "serial communications with ANSI/VT100/xterm escape codes". The Wayland remoting protocol is in an even better position to adopt a rational design.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 1:10 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>I'm not seeing that at all. Your examples all come from the legacy serial terminal and its escape codes, and do not apply to GUIs.

They do. The whole X-Windows uses exactly the same architecture - series of 'escape codes' over a serial line (Unix socket or TCP pipe). And the same argument apply - X works poorly both in remote AND in local cases.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 15:29 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> The whole X-Windows uses exactly the same architecture - series of 'escape codes' over a serial line (Unix socket or TCP pipe).

That is a gross oversimplification. Yes, they both use serial protocols. Most things do nowadays. However, X11 doesn't use "escape codes"; the protocol is designed around structured messages with clear boundaries. More importantly, each X client has its own state and an independent connection to the X server, so they can access the screen and input without conflict. The problem you described are an artifact of the particular set of protocols used for serial terminals, not serialized protocols in general.

> And the same argument apply - X works poorly both in remote AND in local cases.

To say it works "poorly" in either case is another exaggeration. For what it was originally designed for, it works just fine. Technology has moved on, of course, and the prevalence of client-side rendering means that we now have rather different requirements for efficient rendering than we used to. The core rendering protocol is mostly unused, clients tend to provide pre-rendered buffers, the addition of compositing support means an extra round-trip, etc. However, I don't believe I've _ever_ seen the kinds of problems in X which you've described for TUI applications.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 5:46 UTC (Wed) by khim (subscriber, #9252) [Link] (12 responses)

I've seen the exact same types of problems on local consoles, no X or network transparency in sight.

If you talk *nix local consoles then it's the same problem. Even local console pays the price for network transparency for it, too, works with server⇋client model. The only way to see this in DOS/Windows world is to use some kind of ancient MS-DOS program which requires ANSI.sys (for the same reason). Modern TUIs (which use direct-to-buffer rendering) never experience this problem.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 6:46 UTC (Wed) by dlang (guest, #313) [Link] (11 responses)

no, when you use the actual console (not a terminal window on X on the local machine) there is no network or network transparency layer involved.

For that matter, I've seen the same types of corruptions on serial terminals. again no network transparency layer involved, just basic vt-100 terminal codes

the problem is that the programmer makes assumptions about what is where on the screen and doesn't check that things actually fit there. As soon as things start going out of the expected area, all sorts of problems can happen.

^H instead of backspace happens when the terminal emulation doesn't match what the system is expecting you to use. Again this has nothing to do with X or network transparency and everything to do with simple misconfigurations of the terminal settings.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 15:58 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

There is. Local consoles work through the serial ttys, just as remote consoles do.

>For that matter, I've seen the same types of corruptions on serial terminals. again no network transparency layer involved, just basic vt-100 terminal codes

Exactly. It happens on Unix terminals all the time, but it NEVER happens on Windows.

>^H instead of backspace happens when the terminal emulation doesn't match what the system is expecting you to use.
Yep, because there is no "direct rendering" mode for consoles.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 20:57 UTC (Wed) by khim (subscriber, #9252) [Link] (9 responses)

For that matter, I've seen the same types of corruptions on serial terminals. again no network transparency layer involved

Contradiction detected. Serial terminal protocol is a network transparency layer!

the problem is that the programmer makes assumptions about what is where on the screen and doesn't check that things actually fit there.

The problem is there are no screen in this model. Screen exist "somewhere out there", program does not have [a direct] access to it thus it's forced to work via vt-100 terminal codes layer. This makes trivial things basically impossible, or very hard. The things which worked perfectly on tiny microcomputers (with direct memory access - think MSX) are still broken on the Linux systems.

^H instead of backspace happens when the terminal emulation doesn't match what the system is expecting you to use. Again this has nothing to do with X or network transparency and everything to do with simple misconfigurations of the terminal settings.

Sorry, but no. ^H happens when network transparency layer misbehaves. If you write characters to buffer directly then such mismatch can not ever happen. You may see some strange symbols (for example if you are using encoding with linedrawing characters in different places), but straight lines can never become tangled mess (as it often happens in Linux) because in the programming model with direct access to buffer there are no easy way to create such mess.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 21:27 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>You may see some strange symbols (for example if you are using encoding with linedrawing characters in different places)
Ah. GOST vs. alternative GOST encoding on old printers and video cards. I think I'm going to spend next 2 hours in nostalgia.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 21:38 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (6 responses)

> Screen exist "somewhere out there", program does not have [a direct] access to it thus it's forced to work via vt-100 terminal codes layer.

This should be a clue. You're complaining about artifacts of the VT-100 terminal protocol, not anything inherent in network transparency. I don't think anyone would argue that VT-100 is an ideal arrangement, but its flaws are not applicable to network-transparent protocols in general.

Imagine for a moment, if you will, a serialized terminal protocol consisting of a series of atomic (row, column, style, character) quads. This protocol would be perfectly network-transparent, yet would also be indistinguishable from the direct access you're advocating--the quads and direct writes to the buffer being perfectly interchangeable.

You can even do this with the existing VT-100 protocol provided you have exclusive access to the terminal and don't mind wasting some bandwidth constantly resupplying position and style information the terminal already has.

More generally, *any* interprocess communication protocol can be transformed into an equivalent "network-transparent" version based on the exchange of serialized messages; the point of designing for transparency up front is to make the serialization more efficient by preserving the original, higher-level representation, e.g. rendering commands rather than raw video, and by providing for high latency and being conservative of bandwidth, both of which tend to be useful properties in the local case anyway.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:19 UTC (Wed) by khim (subscriber, #9252) [Link] (5 responses)

You're complaining about artifacts of the VT-100 terminal protocol, not anything inherent in network transparency.

Actually that's both. These are artifacts of VT-100 protocol which are typical for a systems with “efficient network transparency”.

I don't think anyone would argue that VT-100 is an ideal arrangement, but its flaws are not applicable to network-transparent protocols in general.

Sadly they are. When you see garbage in your console and when you see overlapping text in your [remotely served] Firefox it's the exact same failure: bugs and inconsistency in unnecessarily complex (from local use POV) protocol which is inconsistently/buggily implemented.

Imagine for a moment, if you will, a serialized terminal protocol consisting of a series of atomic (row, column, style, character) quads. This protocol would be perfectly network-transparent, yet would also be indistinguishable from the direct access you're advocating--the quads and direct writes to the buffer being perfectly interchangeable.

Well, sure. This is VNC-like remote display protocol advocated by Wayland developers.

You can even do this with the existing VT-100 protocol provided you have exclusive access to the terminal and don't mind wasting some bandwidth constantly resupplying position and style information the terminal already has.

You can not. You can write one such program, but it'll be exercise in futility because all other programs expect to use "network-transparent" VT100-based protocol.

More generally, *any* interprocess communication protocol can be transformed into an equivalent "network-transparent" version based on the exchange of serialized messages; the point of designing for transparency up front is to make the serialization more efficient by preserving the original, higher-level representation, e.g. rendering commands rather than raw video,

Bingo! And this is exactly where you introduce multitude of bugs and inconsistencies. It's trivial to implement Windows-console or Wayland protocol: it's very simple, and very robust API. When you add high-level primitives you add complexity which leads to problems. For example if you offload text drawing to the server then you lose the ability to match your pre-rendered picture and your drawn-on-screen text (because you must use exact type of antialiasing in both cases). And the more complexity you add to your protocol the bugger is the outcome.

and by providing for high latency and being conservative of bandwidth, both of which tend to be useful properties in the local case anyway.

Nope. GPUs can very efficiently blend buffers. There are no need to bother with all these optimization unless your program requires them. Developer can decide if they want to create perfect rendering of the font (remember this article which showed example in which each line has a 1/10th pixel shift, so that, in the run of 30 lines it gradually (gradually!) accumulates 3 extra pixels?)…, or go with fast and loose implementation.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 23:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

>You can not. You can write one such program, but it'll be exercise in futility because all other programs expect to use "network-transparent" VT100-based protocol.

Well, you can. By writing terminal emulation working within another terminal emulation. Sort of like 'screen' does.

But it kinda proves our point :)

Wayland - Beyond X (The H)

Posted Feb 16, 2012 0:41 UTC (Thu) by cmccabe (guest, #60281) [Link] (3 responses)

What is your point exactly? That you like direct-mapped text consoles better than network-transparent ones?

That would take us back to the days of the Commodore 64, when remote administration was impossible. Of course, networking was primitive and clunky, so maybe that was a blessing in disguise. And of course the C64 NEVER experienced screen corruption. Oh wait, no, it did-- due to two things: flaky hardware and buggy software. The same things that cause screen corruption and other bugs today.

It's possible that HTML5 and similar technologies will make X11's network transparency obsolete. That might be a valid argument to make. Arguing that we should not implement network transparency because it hurts your poor little brain is not. It's a feature that people want-- deal with it. And yes, people would rather have something with a bug or two that does what they want than something simple and featureless which is only useful as a doorstop (like the Windows console.)

Wayland - Beyond X (The H)

Posted Feb 16, 2012 1:07 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Our point is that local direct-rendering protocols work better than remote ones, given the same amount of work.

It's possible to design a good remote graphics protocol, but it's VERY non-trivial to make it perfect. It's so non-trivial that even simple text-based rendering is still imperfect after 35 years of development.

>And yes, people would rather have something with a bug or two that does what they want than something simple and featureless which is only useful as a doorstop

Would you use a car that spontaneously ejects a driver (even on a highway) sometimes but also has a nice set of skis for downhill car skiing?

I don't think so. And so do most of people. Besides, I'm seeing TeamViewer and Gotomeeting being used several orders of magnitude more than X remoting.

Wayland - Beyond X (The H)

Posted Feb 20, 2012 0:23 UTC (Mon) by cmccabe (guest, #60281) [Link] (1 responses)

Text-based rendering is imperfect on Linux for the same reason that HTML5 is a mess. Whenever you start talking about network protocols, you're talking about communication between different systems. It's a good guess that the vendors of many of those systems are competing with each other and have no incentive to make things work smoothly. In fact, they often have the opposite incentive.

> Would you use a car that spontaneously ejects a driver
> (even on a highway) sometimes but also has a nice set of
> skis for downhill car skiing?

There were 33,000 road fatalities in the United States in 2009. Cars are dangerous. But apparently people are willing to take the risk of driving them anyway. It's about risk versus reward.

> Besides, I'm seeing TeamViewer and Gotomeeting being used several
> orders of magnitude more than X remoting.

Gotomeeting is Windows software, so I don't see how it's relevant here. You might have stayed on topic and mentioned VNC or HTML5 as X11 replacements.

I wish the Wayland advocates would be more specific about what they are offering in exchange for network transparency. So far, all I've seen is "it's like X, but more efficient," which isn't exactly an inspiring battle cry. But I haven't had time to read all of the documents, just the short summaries that I come across.

Wayland - Beyond X (The H)

Posted Feb 20, 2012 12:58 UTC (Mon) by dgm (subscriber, #49227) [Link]

> I wish the Wayland advocates would be more specific about what they are offering in exchange for network transparency.

What Wayland brings to the table is simplicity. It's much simpler that X11 _because_ it doesn't have to support network transparency. And that's not in exchange of network transparency, you can run X11 on top of Wayland. Put another way: by removing the network from the equation, and unifying the server, window manager and compositor, you get a design that is workable, and can serve as the base for a remote protocol, if that's what you need, but without the penalty imposed in the local clients.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 3:14 UTC (Fri) by jschrod (subscriber, #1646) [Link]

^H happens when network transparency layer misbehaves.

I really thought you had something to tell.

*PLONK*

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:39 UTC (Tue) by daglwn (guest, #65432) [Link]

> Why? It's not needed with GDB, why it's requirement for your debugger?

Perhaps because our debugger isn't gdb?

Not all the world is FSF.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:42 UTC (Tue) by jonabbey (guest, #2736) [Link]

We're moving to an infrastructure in which our browsing hosts are allowed to access the Internet pretty freely, but all of our internal systems are running in an extremely locked down network, with only an ssh tunnel allowed to the 'open' zone to run a remote web browser.

All the juicy data stays inside, all the filesystems exposed to the wonderful world of internet malware stays outside.

This kind of a setup doesn't require X11 over RDP, but it does work quite well with X11.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:10 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

We routinely use x11vnc on large compute instances. Works just fine and doesn't even require root permissions.

In fact, I have a set of scripts for SLURM to start a task with x11vnc and connect to it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:56 UTC (Tue) by andrel (guest, #5166) [Link] (2 responses)

VNC is the recommended way to remotely visualize from Texas Ranger and Texas Longhorn. So at least some supercomputer centers already have it installed.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:39 UTC (Wed) by daglwn (guest, #65432) [Link] (1 responses)

Holy crap, that's a complicated procedure! ssh -X is so much simpler and doesn't require running a GUI server on the remote machine.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 17:33 UTC (Wed) by andrel (guest, #5166) [Link]

Using "ssh -X" is certainly much simpler than VNC. Too bad it doesn't work. You can't run a reasonably complicated GUI program, say paraview, down an SSH tunnel to a supercomputer in a different time zone and get science done. But VNC works just fine.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:17 UTC (Tue) by copsewood (subscriber, #199) [Link]

"I'm curious; to all those people that say X11's network features are useful, can you show me examples of what you do with it?"

In my case teaching my students by doing demonstrations of various Linux hosted applications, diagnostics and network investigations using classroom Windows PCs behind a very restrictive firewall connected to the classroom projector. E.G. I can demonstrate IPV6 applications and various DNS and security tests etc. which are completely unavailable on my university network. Putty, XMing and X forwarding is my friend, as is having a faster uplink on my home network than I had a couple of years ago. I also use this to access my home PC applications and email often running inside consoles. The SSH tunnel also provides for a very secure application level VPN which I can carry around with me on a USB stick and use on any Windows PC.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:55 UTC (Tue) by wmf (guest, #33791) [Link]

I use X forwarding when I just want to remote one app; it avoids the visual distraction of having a whole remote desktop. Also, VNC at least requires you to start a server while X over SSH just works.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:14 UTC (Tue) by flashydave (guest, #29267) [Link]

I'm curious; to all those people that say X11's network features are useful, can you show me examples of what you do with it?

I work in a windows shop but have a bunch of Linux machines only accessible (through a firewall) using ssh or rdp. SSH + X forwarding to a windows x server works great. Rdp doesn't. if a am VPNed in from home SSH +Xforwarding to a real X server worlds great.

I need to access the odd GUI based app at home from work. SSH+ X forwarding works great.

I think you get the picture.

Client/server confusion?

Posted Feb 14, 2012 3:33 UTC (Tue) by Max.Hyre (subscriber, #1054) [Link] (13 responses)

Back when I started paying attention to X, everyone carefully pointed out that ``client'' and ``server'' were backwards wrt general usage. I.e., the client was the application back on the mainframe, and the server is X here on my laptop.

In this thread, a lot of the uses of those two words don't make sense (I think) unless seen from the other point of view.

Are people playing fast and loose with the words, or (more likely) am I just painfully confused? (Keep in mind that I have to take a break from discussions of X every ten or fifteen minutes to re-clarify.)

Client/server confusion?

Posted Feb 14, 2012 3:44 UTC (Tue) by dlang (guest, #313) [Link]

people are playing fast and loose with words (including me)

Client/server confusion?

Posted Feb 14, 2012 4:07 UTC (Tue) by neilbrown (subscriber, #359) [Link] (11 responses)

The problem is that general usage is wrong (so common ....).

Machines are not clients or servers. They are ... machines.

Machines run processes. Each process can be a server or a client or both.
In the context of a particular service (e.g. X11 or DNS or SMTP to HTTP) a particular process is usually either a client or a server, not both (though there are proxies).

So Xorg is a server that runs on my laptop. xterm is a client that runs in my basement, on a machine that also runs apache and exim (servers) and squirrelmail, which is both a client (of the pop server that runs on the same machine) and - via apache - a server that serves HTTP to where-ever.

I blame MS-Windows for creating the false distinction between server-machines and client-machines, because you purchased either a 'server' version of MS-Windows or a 'client' version. There really is no such thing. There are only client and server processes.

(and "main-frame"??? Seriously? Does that term even mean anything since about 1980? except to Hollywood)

Client/server confusion?

Posted Feb 14, 2012 6:29 UTC (Tue) by shmerl (guest, #65921) [Link] (1 responses)

Well, Hollywood isn't the only user of supercomputers.

Client/server confusion?

Posted Feb 14, 2012 21:26 UTC (Tue) by neilbrown (subscriber, #359) [Link]

The reference to Hollywood was to the way characters in movies and TV shows will throw around the word "mainframe" because it sounds impressive, not because it is actually the correct term. I wasn't suggesting that Hollywood actually used mainframes.

Client/server confusion?

Posted Feb 14, 2012 6:33 UTC (Tue) by JohnMorris (guest, #73531) [Link] (1 responses)

> (and "main-frame"??? Seriously? Does that term even mean anything since about 1980? except to Hollywood)

http://blogs.nasa.gov/cm/blog/NASA-CIO-Blog/posts/post_13...

Client/server confusion?

Posted Feb 14, 2012 21:39 UTC (Tue) by neilbrown (subscriber, #359) [Link]

I know IBM like to keep the term "main-frame" for their Z-series, but they look a whole lot more like mini-computers to me.

The point of a main-frame is that there were other subordinate frames. The main-frame had the cpu and core-memory. The other frames had tape drives and drum storage and modems punch-card readers and other specialised equipment.

So yes - people still use the term. But does it really *mean* anything? Or it is just an IBM marketing term?

Client/server confusion?

Posted Feb 14, 2012 9:55 UTC (Tue) by epa (subscriber, #39769) [Link] (1 responses)

Curious - why run xterm on the remote machine and send X11 protocol over the network? Wouldn't it make more sense to run a local xterm with an ssh session inside that?

Client/server confusion?

Posted Feb 14, 2012 21:32 UTC (Tue) by neilbrown (subscriber, #359) [Link]

> Curious - why run xterm on the remote machine and send X11 protocol over the network?

Hmm.. I cannot give a good answer, though I know I did this all the time back when I was a sys-admin.

I guess it was a poor example. How about "rhythmbox is a client that runs on the box in the corner which is plugged into the nice speakers". Wouldn't want to run that locally on my notebook - speakers are too tinny.

Client/server confusion?

Posted Feb 14, 2012 16:21 UTC (Tue) by ThinkRob (guest, #64513) [Link]

(and "main-frame"??? Seriously? Does that term even mean anything since about 1980? except to Hollywood)

Oh yeah. Definitely.

Client/server confusion?

Posted Feb 14, 2012 17:38 UTC (Tue) by Max.Hyre (subscriber, #1054) [Link] (2 responses)

Ahem. Note the length of your response. I defy you to ask the question so succinctly and clearly as I just did. :-)

The distinction you note is indeed accurate, machines per se are neither, but then how do you differentiate the two processes? Standing way back and squinting, it appears that in most (all non-X?) cases, the client is the process ``closest'' to the human, the one most directly supplying the info of interest thereto. The server is the process ``furthest'' from the human, gathering or generating said info. Thus, Horde off at my ISP is the server for e-mail, while Thunderbird here on my laptop is the client.

However, X's idea is that the process writing to my screen is the server, offering display services to the processes gathering or generating the info.

My head hurts...where's that aspirin?

Client/server confusion?

Posted Feb 14, 2012 18:56 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

> ... how do you differentiate the two processes?

Server processes manage resources--data, compute capacity, I/O devices, etc. Client processes initiate relationships with server processes for the purpose of accessing those resources.

Client/server confusion?

Posted Feb 14, 2012 21:53 UTC (Tue) by neilbrown (subscriber, #359) [Link]

I'm not really sure what you are defying me to do ... but I would expect to need more words to correct a misconception that to teach a new concept..

> the client is the process ``closest'' to the human
> The server is the process ``furthest'' from the human

This paints a very consumer-oriented view of computing. The human is just receiving services from something far away.

I don't see it that way. I want my device (in my hand even) to be providing services. I want my mail server, my file server, my media server, my git server all to run on my phone (with suitable backups of course, possibly on my wife's phone or in my freedom box) Then any old keyboard+screen could provide display and input services to my mobile-computing-device, and it could provide information services to me.

Both the client and the server are close to me - close enough that I can control them, not be controlled by them.

Client/server confusion?

Posted Feb 14, 2012 19:31 UTC (Tue) by leoc (guest, #39773) [Link]

IBM still sells many metric tons of mainframes every year.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 9:15 UTC (Tue) by janpla (guest, #11093) [Link] (6 responses)

Hmm, as far as I can see the argument goes something like "Wayland is necessary because X is rubbish, because X can do too much".

Somehow that argument fails to convince - to my mind, the problem of "too many options" can be solved fairly easily with a sensible set of defaults and/or a good configuration tool, whereas it is a lot harder to solve the problem of features missing because the tool just doesn't support it.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 9:56 UTC (Tue) by epa (subscriber, #39769) [Link] (3 responses)

The problem of "too many options" bites you much harder if you are an implementer. You have to add and test support for all the options and all their weird combinations, even those that are hardly used any more or those that could easily be replaced with some simpler feature. Keith P. has first-hand experience of this.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 13:25 UTC (Tue) by sorpigal (subscriber, #36106) [Link] (2 responses)

It would be one thing if wayland were a "better X" - meaning exactly like X in all the ways we like but with a deliberate break of backwards compatibility to get rid of cruft. But it's not.

It seems like ultimately Wayland will be nothing more than a new subsystem used by X and that nothing else will change. I can't forsee getting rid of X any time soon for a replacement that isn't a lot like X, but I can see swapping out the guts of X and modernizing them. That's okay.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 14:05 UTC (Tue) by AndreE (guest, #60148) [Link]

"Modernizing" X requires gutting and reworking much of it's original architecture. We don't need a "better" X, we need "better than X". The actual article makes this pretty clear.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 9:23 UTC (Wed) by jku (subscriber, #42379) [Link]

That is the SVN strategy: "be a better CVS". At the time it sounded like a fairly good idea. Nowadays, I'm sure I'm not the only one who only touches SVN when it's absolutely necessary, and would never choose it for their own projects.

Better X is not enough.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 12:30 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

There are a lot of legacy limitations in X, not all of which can be hacked around as people tried this last decade (for example, any recent keyboard will have keys the kernel recognize but X doesn't, because of protocol limitations)

I guess it will go the same way as the xfd font backend ten years ago: x devs get so fed up with legacy problems they move to something else, and no one steps up to do anything but maintain the old cruft in life-support no-enhancements-or-fixes mode. And apps that do not follow slowlink sink into obscurity.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 17:42 UTC (Tue) by daglwn (guest, #65432) [Link]

Oh, I think the case for Wayland is very good. The X code base is a mess and a good large percent of it really isn't used. It's a maintenance nightmare.

However, nothing I've read indicates that the Wayland people understand just how many people depend on remote X or some equivalent. If they provide an equivalent that performs as well or better and is just as easy to use (that means in particular no setup required on the remote machine), I'm all for it. If not, Wayland is next to useless for me.

Window Management

Posted Feb 14, 2012 17:52 UTC (Tue) by tjc (guest, #137) [Link] (6 responses)

The X Window System was, though, only concerned with the very basic elements of rendering graphics; "mechanism not policy" was an often heard reason for why the MIT X Consortium would not define standards for buttons, scroll bars and other UI elements. Even window management was left up to vendors; UI toolkits appeared from Unix vendors trying to differentiate themselves, such as AT&T's Open Look and the OSF's Motif.

I'm concerned about the "even window management was left up to vendors" part. Does this imply that Wayland does not support replaceable window managers, or am I reading too much into this? If there's going to be "one window manager to rule them all," experience teaches that it's probably going to suck.

Window Management

Posted Feb 14, 2012 18:09 UTC (Tue) by aleXXX (subscriber, #2742) [Link] (2 responses)

AFAIK kwin already supports wayland, so the window manager should seems ot be replaceable.
...but drawing window decorations is done in the client process AFAIK.

Alex

Window Management

Posted Feb 14, 2012 22:20 UTC (Tue) by tjc (guest, #137) [Link] (1 responses)

> but drawing window decorations is done in the client process AFAIK

I seem to remember something about that too. I hope this doesn't end up with different applications having different window management capabilities. That would be chaos.

Window Management

Posted Feb 15, 2012 11:12 UTC (Wed) by Sho (guest, #8956) [Link]

No, the compositor / window manager can still do the decos. We already have this in kwin, too.

Window Management

Posted Feb 14, 2012 18:13 UTC (Tue) by raven667 (subscriber, #5198) [Link] (2 responses)

The above paragraph is strictly talking about how X was designed. As far as Wayland, my understanding from reading the docs is that the compositor will be the window manager. The Wayland architecture, as I understand it, is that apps will output directly to the graphics card and the compositor/window manager will coordinate user input/output and programming the graphics without requiring all apps to round trip all data through the compositor.

It actually isn't a big change in a lot of ways.

Window Management

Posted Feb 14, 2012 22:18 UTC (Tue) by tjc (guest, #137) [Link] (1 responses)

> my understanding from reading the docs is that the compositor will be the window manager.

Yeah, that's what I'm concerned about. I would much rather have window managers and compositors as separate components that the user can select according to their preference.

Window Management

Posted Feb 14, 2012 23:39 UTC (Tue) by nix (subscriber, #2304) [Link]

That doesn't work very well even now. They tread on too much of each others' turf.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 12:35 UTC (Wed) by njd27 (subscriber, #5770) [Link] (15 responses)

It would be nice if all the concern about the lack of network support in Wayland translated into working code rather than long comment threads on LWN.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 18:35 UTC (Wed) by dlang (guest, #313) [Link] (14 responses)

that's hardly possible when the Wayland advocates (if not their developers) just respond with "a remote protocol isn't needed, nobody uses network transparency any longer"

It would require very significant changes to the current design, this isn't just a matter of adding a little code.

People are speaking up because they hope to convince the Wayland developers/advocates that this is something that's needed, and therefor something to think about rather than dismiss.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 0:06 UTC (Thu) by HelloWorld (guest, #56129) [Link] (1 responses)

> It would require very significant changes to the current design
No, it wouldn't. The Wayland protocol deals with input and compositing. How would a remote rendering protocol necessitate any changes in the protocol for the compositor?

Wayland - Beyond X (The H)

Posted Feb 16, 2012 9:23 UTC (Thu) by khim (subscriber, #9252) [Link]

If you don't have anything else except input and compositor the you can not implement efficient network transparent protocol.

At this layer you just have to deal with too large stream of unstructured information.

And current Wayland design don't have any other non-optional layers.

Network-transparency advocates demand addition of such layer - because it'll make theirs life easier. Why everyone else should suffer¹ is not clear.

────────────
¹) And yes, they will suffer because such layers will at minimum introduce additional work which will suck power and in all likelihood will have additional bugs which will hurt eyes of users.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 1:39 UTC (Thu) by bloopletech (guest, #71203) [Link] (10 responses)

I have read the entire thread, and I have seen ~10 unique people saying they use X network transparency. Considering anyone who uses X network transparency is likely ot be watching this debate, it seems a very small group of people who want to externalise what is apparently a ton of work to other people.

You (I'm referring to all the people who are talking about wanting network transparency, not specifically dlang), talk about what *you* want and what *you* need, but I reckon you don't care one whit about what *I* want or need.

What *I* want is a reliable desktop manager/window manager/graphics rendering/video player. As far as I am aware, and I am only slightly clueful on this, is that the currenct X codebase/structure of X + DRI2 + KMS + GTK + Gnome etc. etc. etc. makes this goal much harder to achieve. To me, *this* is the goal of Wayland: to make a quality GUI desktop system work, and work well, with the minimum of work.

AFAIK Wayland will have some sort of network-ability and this will all be a moot point, but if you want straightforward X-style network transparency, isn't it on *you* to provide it?

Aren't Wayland's developers entitled to code on what they want? I thought one of unix/linux's central tenets was the freedom to work on what you want; rather it seems to be a number of users complaining to other people, telling them what they should or shouldn't do. It seems rude and obnoxious of me to expect other people to do work you're not willing to do yourself.

This sense of overblown entitlement, telling everyone else what they should be doing while not willing to put in any work themselves, is an endemic and very frustrating problem in the linux^Hlwn world.

I'm not trying to say there's no use, or that no one uses, X network transparency. But just because a small percentage of users want something, doesn't magically mean it's the right thing to do for the vast majority of users.

What this really boils down to is that the X network transparency proponents are scared stiff that if Wayland is generally adopted and is much easier to support than X, that developers won't bother supporting X any more. I say that if X is so hard to support, maybe you should be working towards making X easier to use; or working to add X network transparency to Wayland. Alternatively, please refrain from telling developers that they should do extra work just for you; is it not their decision to support what they want?

Wayland - Beyond X (The H)

Posted Feb 16, 2012 3:35 UTC (Thu) by viro (subscriber, #7872) [Link]

I don't see any Weyland developers in this thread; as for the people using X over network, keep in mind that not everyone is willing to step into khim, so watching the thread is not the same as replying into it. Some things are simply too foul to touch and his/her/its kind of demagogues is very high on that list, as far as I'm concerned.

Personally, I have no problem whatsoever with Weyland crowd developing what they are developing; it's clearly not for me in the current form, since I _am_ using remote X all the time (including right now), but I don't buy the conspiracy theories in general, let alone the culture war bullshit that seems to be implied a lot in this thread. So add that to your statistics, for whatever it's worth...

Wayland - Beyond X (The H)

Posted Feb 16, 2012 23:55 UTC (Thu) by khc (guest, #45209) [Link]

I use X network transparency and I am watching this thread, but haven't commented so, mostly because the discussion mostly doesn't involve people who actually work on wayland, and convincing people like you that the feature is useful seems pointless to me. I should also note that the number of people who claim that no one uses X network transparency isn't that high either, so 10 people in this sample is likely to be significant.

That said, I am not too worried. By the time X11 is phased out there will be an acceptable solution (however it's implemented), precisely because enough people find it useful.

Wayland - Beyond X (The H)

Posted Feb 17, 2012 2:09 UTC (Fri) by jschrod (subscriber, #1646) [Link] (5 responses)

I *am* using X network transparancy daily, and I haven't bothered to participate in discussions here since no Wayland developers are involved, it's not worth it.

But then, I respond to an obvious troll named bloopletech, so maybe I should have done so. Congratulations to your trolling, sir. You are a good one.

Wayland - Beyond X (The H)

Posted Feb 22, 2012 0:31 UTC (Wed) by bloopletech (guest, #71203) [Link] (4 responses)

I am honestly sorry if this comes across as trolling.

My laptop has an AMD chipset. This has necessitated a lot of messing about with drivers and broken upgrades, and basically a lot of spent time and effort. At the time this was really, really, really frustrating and angering. I often had a broken, or not-working-very-well system.

I have generally not complained about this online, because the difficulties were inherent to the status quo - ubuntu moves really fast which leaves proprietary drivers behind, the open source drivers guys were working like mad to get the drivers out, but only had limited resources.

I have also generally not complained because I don't like reading entitled whinging, so I try not to produce it myself (sorry, that was snarky ;).

But now the status quo appears to be changeable, in favour of easier/better driver development (that is only an assumption, I have no idea yet if it is true). At least, upgrading your drivers [as a user] will be much easier (this part I'm fairly sure of).

My real frustration is that there seems to be a group of people who do not understand that there are more things pulling on the steering wheel than just their needs. I do realise this applies to me too, but afaict their use case will not be massively affected, whereas my use case *might* be massively improved.

I do still think there is a disruptive sense of entitlement; but I've already written enough inflammatory material on that topic.

Wayland - Beyond X (The H)

Posted Feb 22, 2012 0:44 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

How will Wayland change this? it will still require that the video drivers be written for the particular chip.

I really don't think that the network transparency part of X is a significant factor in the problem of getting working drivers.

At least AMD provides documentation, so the folks working on opensource drivers for their cards don't have to reverse engineer everything like the nVidia folks do.

Wayland - Beyond X (The H)

Posted Feb 22, 2012 1:47 UTC (Wed) by bloopletech (guest, #71203) [Link]

Apologies; I'll try to be more specific.

I'm sorry this information is vague, it's been a while since I've had to deal with these driver issue. My drivers work pretty well these days actually; my concern is more that new drivers for new series (oversimplifying it, AMD redoes their chips every few years, and you have to build new drivers for these new chips) will be as difficult to develop, and as difficult to install use and troubleshoot, as they were in 2010/2011.

My understanding is that driver development at the moment is intertwined with X excessively, and that this makes driver development more difficult. The X.org wiki, freedesktop project wiki and more specifically http://www.x.org/wiki/RadeonFeature have more detail on this I think; these were the resources I used mainly when trying to get my graphics to work.

I know that the driver I have installed depends intimately on your kernel version and also you Xorg version, because some parts are in the kernel, and some parts are in X, and these all have to agree etc etc.

Another more nebulous issue is that with more (and more complex) layers in the graphics stack, it becomes much more difficult to troubleshoot issues that you have. I used to have a lot of VSYNC issues on my machine, until I learned a lot of estoeric detail about how to get it to work. It also becomes more difficult to make sure the user's desire at the surface gets through to the bottom of the stack.

My understanding is that by having a smaller and clearer target to develop and test against, driver dev will be easier; and that removing layers from the stack it also becomes easier to test and configure etc.

Of course it's not X network transparency itself that makes the development more difficult; it's developing against X in the first place.

My understanding could be completely wrong; if there are any driver devs, it would be really good to hear what they think of wayland and whether it would be easier for them.

I am massively massively grateful for the work of the open source driver developers, and I hope I haven't put words into their mouths here.

Wayland - Beyond X (The H)

Posted Feb 23, 2012 23:05 UTC (Thu) by jschrod (subscriber, #1646) [Link] (1 responses)

But the post that I answered to had nothing about your difficulties with X per se, but was only about X network transparency.

We should start with the fact that when you use X on a local desktop, X network transparency is not involved at all. Since quite a long time, local graphics output in X access the graphics card directly. This was first done by the X software itself, and recently some/most of that hardware access was moved to the Linux kernel by means of Kernel Mode Setting (KMS).

The problem for Linux is that the graphics card API for fast 3D graphics is often not published by the hardware manufacturer. I fully agree with you that the state of graphic support is not satisfactory. In fact, I'm more pessimistic than you; some things that worked in my Unix/Linux environments since 1990 is more instable, since that move to KMS. That nowadays the main recommendation for non-working graphic setup is "boot with nomodeset" speaks volumes, IMHO. But I don't blame the developers, hardware has changed too much, and the road they took on the kernel side -- i.e., the hardware drivers -- seems to be a sensible one. Nevertheless I'm still not able to use VMware with 3D acceleration on standard hardware because some OpenGL primitives are not supported. And then I read here that new developments demand full GL support on notebooks, and I shudder.

Thus, I think your conception of problems in the Linux graphics stack is right on spot, it might be even worse than you see it. But that has nothing to do at all with X transparency, and Wayland won't change the situation with non-sufficient hardware documentation/drivers. So you might want to address your rants to issues where they are appropriate and leave network transparency to us who need it daily.

Cheer, and apologies for calling you a troll.

Joachim

PS: Disclosure: I am biased in favor of X, if that isn't clear by now. When I started to use X10 in 1987, and helped to port X11R4 to several architectures in 1988, I always regarded it as a flexible and trustworthy design, and still think an evolutionary X12 would be better than Wayland. We see in the Linux kernel year after year that evolutionary developments are better than big-bang approaches. This is an important lesson that many players in the graphics stack development community should heed, IMNSHO. It doesn't help that I have friends who were active in the X development community for many years, nor does it help that my own open source "home-base" is the TeX community who is equally conservative concerning user-space changes...

Wayland - Beyond X (The H)

Posted Feb 23, 2012 23:56 UTC (Thu) by khim (subscriber, #9252) [Link]

We see in the Linux kernel year after year that evolutionary developments are better than big-bang approaches.

What are you talking about? Linux kernel certainly is developed using "big-bang approach". For example O(1) scheduler was replaced with CFS. USB, WiFi, Networking Stack - everything was replaced quite a few times.

True, linux kernel developers rarely replace everything at once - but so do Wayland developers: at first only some applications should be changed (Window Managers and compositors), later other pieces will be replaced as well. It'll be quite a few years till X11 itself can be removed from the picture!

Wayland - Beyond X (The H)

Posted Feb 24, 2012 21:51 UTC (Fri) by jdobbs1010 (guest, #83118) [Link] (1 responses)

I use X applications over a network every day, as part of my work as a software developer in a largish company. Typically running Eclipse on server-class linux hardware, with a Cygwin X server on a Windows (XP of course - the corporate standard!) desktop. Eclipse on Linux, because I'm developing C++ server applications for Linux. Also DDD, occasionally SunStudio on Solaris (because there's still a few Solaris-only servers to maintain). The company only officially support vnc for this type of thing, but I didn't like it much last time I tried it (a few years back, I admit), and X has solved the 'application running on a different machine to the display' requirement ever since I can remember using X (ie since around about 1993).

Looking around the corporate environment (i.e. the cube farm where I sit), there are no people using a Linux desktop at work (its not the corporate standard, yet!). There are dozens of developers using X network transparency to do similar work to me. OK, maybe software developers are different, but you will also find in corporate environments, long-ago developed X applications that are deployed to users using X servers such as Exceed (another corporate standard). Maybe not as many as in the past, but these applications are not going away (there's a 3270 terminal emulator one every corporate desktop, too).

Another corporate standard in widespread, and on-going use, here is Citrix XenApp. Quoting Wikipedia...

"Unlike framebuffered protocols like VNC, ICA transmits high-level window display information, much like the X11 protocol, as opposed to purely graphical information."

Its the Windows implementation of X network transparency - companies love it, and employees use it a lot. This is a requirement with a large user population, not a small one.

To say no one uses X network transparency reflects your computing environment, but not mine.

Wayland - Beyond X (The H)

Posted Feb 24, 2012 23:36 UTC (Fri) by BlueLightning (subscriber, #38978) [Link]

> "Unlike framebuffered protocols like VNC, ICA transmits high-level
> window display information, much like the X11 protocol, as opposed to
> purely graphical information."
>
> Its the Windows implementation of X network transparency - companies
> loveit, and employees use it a lot. This is a requirement with a large
> user population, not a small one.

I worked with Citrix a lot in the past and despite some real issues on the administration side, ICA as a protocol and Citrix in its implementation of it works extremely well. But you know what? As pointed out previously in this discussion it was a retrofit on top of a non-networked windowing system; so it kind of suggests that people who are saying it's not possible to have such network transparency without designing it in from the beginning might just be completely wrong.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 11:53 UTC (Thu) by nye (subscriber, #51576) [Link]

>that's hardly possible when the Wayland advocates (if not their developers) just respond with "a remote protocol isn't needed, nobody uses network transparency any longer"

Ah, I see the problem - you've been reading an alternate-universe version of the thread.