+++ to secure your transactions use the Bitcoin Mixer Service +++

 

|
|
Subscribe / Log in / New account

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Over at Phoronix, Eric Griffith has attempted to set the record straight on X and Wayland, with assistance from X/Wayland developer Daniel Stone. He looks at the failings of X and the corresponding "fixings of Wayland", along with some misconceptions about the two and some generic advantages for Wayland. "'X is Network Transparent.' Wrong. [It's] not. Core X and DRI-1 were network transparent. No one uses either one. Shared-Memory, DRI-2 and DRI-3000 are NOT network transparent, they do NOT work over the network. Modern day X comes down to synchronous, poorly done VNC. If it was poorly done, async, VNC then maybe we could make it work. But [it's] not. Xlib is synchronous (and the movement to XCB is a slow one) which makes networking a NIGHTMARE."

(Log in to post comments)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 8, 2013 22:44 UTC (Sat) by nix (subscriber, #2304) [Link]

I'm afraid the whole thing strikes me as so one-sided it borders on disingenuous :( I'd like to like Wayland, but it still gets my hackles up every time I think about it.

Eric's argument for why not to call it X12 is bizarre -- because if it were called X12 people who care about X might care about it, as if they won't care if it's called something else! A better reason for its not being called X12 is that it is clearly not an evolution of X11 in the way X11 was an evolution of X10: it's not a network protocol at all...

"Multi-monitors is a client problem". That's code for "a random half of your applications will eventually support your second monitor: the other half won't", and is just as broken as client window decorations for exactly the same reason. How this is better than X, where nothing but SDL (sigh, fixed in SDL 2) needed hacking for multiple monitors on my system, is not at all clear. (I have a good few (non-free) games that insist on rendering on only one monitor, which is reasonable, but every one of them without exception can be forced to render on a specific one and turn the other one off.)

Nobody uses core X, he says. My Emacs disagrees, it's running on a headless server using network transparency, plus client-side fonts, right now and working quite happily with very low volumes of network traffic and effectively instantaneous screen updates.

"A higher-performance version of VNC", the protocol in which scrolling a nearly-completely-black screen with a bit of text on it over a 1Gbps network takes half a second or so and is juddery as hell. Wonderful. (From other comments on LWN, I understand that VNC is not quite so bad anymore, and that this should be fixed 'properly' by having every single toolkit independently reimplement network transparency, only not a single toolkit has actually done that to my knowledge. Doubtless they will all use totally different authentication mechanisms and have their own network-related security holes. If they reimplement it at all, which I doubt.)

"Every frame is perfect". I don't understand why this is such an issue. Total amount of flashing or tearing I have had in X since I got a graphics card newer than an S3: none, not even when doing simultaneous overlapping textured video playback and oolite. I don't know what the hell the Wayland people are doing with X to make it tear all the time, maybe it's compositing. If compositing is making X creak at the seams this much, maybe a rethink is necessary, but personally given the choice between network transparency and wobbly windows I'd jump at network transparency every time.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 8, 2013 22:51 UTC (Sat) by josh (subscriber, #17465) [Link]

> Nobody uses core X, he says. My Emacs disagrees, it's running on a headless server using network transparency, plus client-side fonts, right now and working quite happily with very low volumes of network traffic and effectively instantaneous screen updates.

You've just proven the point. Emacs uses client-side drawing and client-side fonts, like everything else these days. The only relevant applications left using core X drawing/font/etc primitives, or anything other than windows and pixmaps, are the X test suites.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 8, 2013 23:43 UTC (Sat) by nix (subscriber, #2304) [Link]

You've just proven the point. Emacs uses client-side drawing and client-side fonts, like everything else these days. The only relevant applications left using core X drawing/font/etc primitives, or anything other than windows and pixmaps, are the X test suites.
Really? Xaw is a client-side drawing library, is it? 'cos my Emacs is using Xaw. It's using it because of a ten-year-old unfixed bug in Gtk whereby disconnecting from the X server, then shutting it down, then reconnecting to the new one, segfaults. Oops! This is... problematic for emacs --daemon usage, so anyone using that (anyone shutting their desktop down overnight and leaving their Emacs running on another machine) is still stuck using Xaw.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 1:02 UTC (Sun) by josh (subscriber, #17465) [Link]

You specifically said "plus client-side fonts" in your description, so I assumed you ran a version of Emacs using client-side fonts.

Do you have a link for the GTK+ bug report about the segfault when connecting to a new X server?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 5:46 UTC (Sun) by dakas (guest, #88146) [Link]

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:05 UTC (Tue) by nix (subscriber, #2304) [Link]

This bug number is somewhat unusual among bugs since it is now wired into the Emacs source code in a warning printed whenever you try to use --daemon on a Gtk Emacs! It has caused a lot of trouble in the past...

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 5:05 UTC (Mon) by Russ.Dill@gmail.com (guest, #52805) [Link]

Wait...why are you running emacs over X? WTF?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 8:19 UTC (Mon) by dgm (subscriber, #49227) [Link]

A typical novice mistake. Everyone worth it's bits knows that The Right Way(TM) to do it is run X over Emacs.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 15:04 UTC (Mon) by dakas (guest, #88146) [Link]

Everyone worth it's bits knows that The Right Way(TM) to do it is run X over Emacs.
No, the right way is to use a shell connection (not X) into the machine in question and have it transparently shuffle the files into your local copy of Emacs.

For example, if you do C-x C-f /ssh:frodo@barad-dur.mordor.xxx:/mnt/doom RET then you'll get secure access to /mnt/doom as user frodo on host barad-dur.mordor.xxx without ever having to leave your local copy of Emacs.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 16:47 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

It was really foolish to allow anyone else write access to /mnt/doom. He really needed a better sysadmin.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 23:58 UTC (Mon) by ssmith32 (subscriber, #72404) [Link]

lol. Just finished up a re-read of the trilogy. Thanks for the chuckle :)

Take care,
-stu

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 3:06 UTC (Tue) by madscientist (subscriber, #16861) [Link]

TRAMP is great, but not always the best solution. At work I have a monster system. At home I have a mediocre system. I want to do compiling, debugging, etc. on my monster system--from within Emacs obviously. Also, I don't want to have to recreate my entire Emacs session at home: I can use emacsclient to bring up a remote frame in my at-work Emacs session, displayed on my system at home, and have all my buffers etc., even unsaved work, right there.

Distributed file access is important, but it's not the only thing.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 5:49 UTC (Tue) by oldtomas (guest, #72579) [Link]

By default, these days TRAMP tries to start processes on the box the current buffer comes from. See https://www.gnu.org/software/emacs/manual/html_node/tramp.... Invoking M-x shell "from within" a tramp buffer will bring you a shell on the remote box, and invoking M-x compile will try to run the compile command there too (Emacs 23.4.1 as it comes with Debian, so nothing too recent here).

So it'd be worth to give that a try. That said, there are doubtlessly advantages to the remote X setup, which I do appreciate in other occassions.

For your case (keeping the session alive), Emacs server might be an option too.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:09 UTC (Tue) by nix (subscriber, #2304) [Link]

Uh... unless you use TTYs exclusively, the Emacs server *relies* on remote X to pop up a frame on the screen in front of you rather than wherever it was started. It's not an alternative to remote X: it *is* remote X, just a rather more unusual variant in which one program can be connected to multiple X "Display"s simultaneously.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 20, 2013 18:28 UTC (Thu) by daglwn (guest, #65432) [Link]

My emacs 24 doesn't pop up frames when using TRAMP to invoke shells.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 25, 2013 20:57 UTC (Tue) by nix (subscriber, #2304) [Link]

Aaah. Sorry, I completely misread it and had everything turned around. You're right, of course. (And that's a nifty feature: how long's it been there, I wonder...)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:04 UTC (Tue) by nix (subscriber, #2304) [Link]

Do you mean "why am I running it remotely"? I'm running it on X to get lots of fonts and colours and keystrokes (I use shift, control, meta, super and hyper in different combinations and regularly wish there were more bucky bits!)

I'm running it remotely because the remote system (actually 'on the other side of my desk' on the other end of an unshared GbE connection, so not that remote) is faster than the local one, has ECCRAM where the local desktop (like most desktops) has normal RAM, has far *more* RAM which Emacs always likes, has the house RAID array local rather than over NFS, and is the machine that I don't shut down every night. Hence emacs --daemon is a lifesaver.

I cannot imagine that this is a particularly rare use case in these days of expensive power in Europe, given that desktops are often more power-hungry than headless servers. (Though it is true that perhaps not all that many people have a headless server at home, it's certainly not rare among developers, and among those developers a hell of a lot of them likely use remote X or would use something like it if it were available on their OS: remote headless servers are a lot less useful if you can't treat them 'mostly like your desktop' for worky stuff. But perhaps the Linux desktop is no longer targetted at developers?!)

As an aside, I do wish TuxOnIce hadn't gone moribund. I used to be able to suspend my desktop rather than shutting it down...

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 8, 2013 23:13 UTC (Sat) by stevenj (guest, #421) [Link]

"Multi-monitors is a client problem". That's code for "a random half of your applications will eventually support your second monitor: the other half won't", and is just as broken as client window decorations for exactly the same reason.
Read "client" as "toolkit". Applications don't roll their own GUI from scratch anymore, so only a few toolkits need to (and probably will) implement the required "client" functionality for the vast majority of applications to benefit.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 8, 2013 23:45 UTC (Sat) by nix (subscriber, #2304) [Link]

Yeah. Hence 'a random half'. The random half using toolkit A, which implemented multi-monitor support, versus toolkit B, which didn't bother. (I've seen just how slowly some toolkits pick up features. I have *no* confidence in them implementing even multi-monitor support properly, let alone the entire network transparency layer that the Wayland boosters appear to believe will be implemented in each one.)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 5:03 UTC (Sun) by butlerm (subscriber, #13312) [Link]

The straightforward way to do this would be to implement a common midlayer graphics API one level higher than Wayland with support for rendering across multiple screens and network transparency. Then the toolkit developers could target that interface instead of requiring those things to be implemented on a toolkit by toolkit basis, which sounds crazy to me.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 8:21 UTC (Mon) by dgm (subscriber, #49227) [Link]

Shall we call it X12?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 17:45 UTC (Mon) by butlerm (subscriber, #13312) [Link]

Two major differences - X is a protocol, this would be a library interface. X requires IPC where it isn't necessary, this would not. The protocols used for network transparency should be independent of the API. X went horribly wrong by wiring the two together - if you use any other protocol, you get the worst of both worlds - a hard limitation to what the X protocol can support and a bunch of gratuitous IPCs to a slow and undignified protocol adapter in-between.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 7:48 UTC (Tue) by mmarq (guest, #2332) [Link]

Un-wire it.

And BTW take it to kronos, what ever gets to be a kronos standard is the one that will win.

I like the idea for compatibility
http://hack.org/mc/texts/gosling-wsd.pdf

Something very simple, even perhaps CoreX11 is too much (don't know), the remote case i would keep the protocol and download a conformant piece to every machine... its client, everybody downloads VNC etc if they wanted.

Most important of all take it kronos... let me see, about **ALL** the industry is there (fame and jobs).

The reality is that you are getting obsolete gentleman, the arguing is intense, but you seem to have lost the boat. Input(X) is bad ? ... what about streaminput ? ( i know NIH)... composition ? there is already a OpenWF http://www.khronos.org/openwf/ ( yes i know NIH) GL ? ... well they are at OpenGL4.3, the all edifice is being build around EGL i think (Linux DS is based on whatever fix for a problem seems the best by a few heads in a particular time, irrespective of others)

X, Wayland, MIR ??? ... i think this isn't going anywhere.

Perhaps Android DS can became full industry compliant (Kronos), and we can scrap all that s**t, no matter if many think that in point A or B their lady is much better.

If everybody coding for X (apps) could continue that would be awesome, but that is the only reason i see to give them the trouble to adopt another window system and protocol... **standard and lasting**... techs particularities are terceary importance, after all software can change all the time(to where is what might not be the wise thing, even if some tech argument is valid)

(it has do to with philosophy, complex systems above the "animal" don't evolve by competition, natural evolution crap, they destroy each other instead, like animals that eat each other... the natural paradigma of the human relation is cooperation not animal fagomania)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 14:51 UTC (Fri) by daniels (subscriber, #16193) [Link]

Khronos's window system stuff (OpenWF, StreamInput, etc) has been around for many years now. And still no-one cares.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 16:25 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

You're reading it wrong...

Multi-display will work without any changes in applications right now. After all, applications won't care about who's going to be displaying their buffers with pixels and the compositor can send them to whatever displays it wants.

But if you are going to do something more complicated, like switchable graphics, then you're going to have to support it within the applications. It'd be nice to have it on the Mesa (OpenGL) level, though.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 7:16 UTC (Sun) by callegar (guest, #16148) [Link]

Flashing and tearing is an issue. The ability to give presentations with no flickering on opengl effects (and particularly fading) is important. And unless compositing is disabled, flickering and flashing are there on X, even with intel or nvidia graphics.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 15:13 UTC (Mon) by drag (guest, #31333) [Link]

with compositing disabled the graphic ugliness of X is made much worse.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:12 UTC (Tue) by nix (subscriber, #2304) [Link]

I have compositing disabled. No flashing. At all. Maybe if I used programs that were really slow to repaint I'd see it -- but I guess none of them are anymore, not with modern CPU speeds. Maybe back in the 90s... heck, I remember when Enlightenment was huge and bloated and slow, while now it's a bit heftier than it used to be and is renowned for being trim and fast!

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 3:53 UTC (Mon) by daniels (subscriber, #16193) [Link]

> Nobody uses core X, he says. My Emacs disagrees [...]

Sure, and so does xeyes.

xeyes

Posted Jun 10, 2013 8:59 UTC (Mon) by oldtomas (guest, #72579) [Link]

Are you serious? My sarcasm-o-meter is giving contradictory readings...

xeyes

Posted Jun 18, 2013 11:27 UTC (Tue) by nix (subscriber, #2304) [Link]

He's being patronizing and sarcastic because, well, as far as I can tell because I've knocked a hole in his argument and he has no constructive response he can give. Depressing.

It would be less depressing if I hadn't been banging on about the same subject in virtually every thread on the same subject here for *years* and if Daniel hadn't been reading those threads as well and hadn't completely ignored them or been just as patronizing in all of those.

I wouldn't make such a fuss, except, again, this workflow is the one in which I have earned every penny I have ever earned. And it's not at all a subtle or unlikely workflow, unlike the workflow of someone making their living from a remote instance of fucking xeyes.

(Why yes, Daniel *has* just made me very angry. Way to piss off your users and make your users suspect that the Wayland developers don't give a damn about how their actual *users* are using the system they're trying to replace, mate. Well done. Very well done. Do I have any confidence in Wayland at all? Not after *that* comment.)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:23 UTC (Tue) by nix (subscriber, #2304) [Link]

Oh, I'm sorry. Obviously the Emacs in which I have done *all my work for the last fifteen years* and have earned *every penny I have ever earned* is only as important as bloody xeyes.

Sheesh. Talk about patronizing.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 19, 2013 0:07 UTC (Wed) by daniels (subscriber, #16193) [Link]

Yes, and I make a living out of vim. What you're saying, effectively, is that X11 is an abomination and inferior to SSH, just because vim under SSH is much more efficient than under an X11 terminal emulator.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 25, 2013 20:34 UTC (Tue) by nix (subscriber, #2304) [Link]

What? I never said any such thing. If you want to invent words and put them in my mouth, you are welcome to, but that still doesn't mean I actually said them.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 25, 2013 20:52 UTC (Tue) by daniels (subscriber, #16193) [Link]

Right, it'd be putting words in your mouth. Just like you saying I think text scrolling is as pointless as xeyes, is putting words in my mouth. EOT I hope.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 12:25 UTC (Mon) by drag (guest, #31333) [Link]

> Eric's argument for why not to call it X12 is bizarre -- because if it were called X12 people who care about X might care about it, as if they won't care if it's called something else! A better reason for its not being called X12 is that it is clearly not an evolution of X11 in the way X11 was an evolution of X10: it's not a network protocol at all...

It probably was a bit tongue in cheek.

As he pointed out in the article X12 has had a sort of 'draft' status for a long time now and has gone no-where. Long before Wayland came along.

If anything the Wayland remoting will be superior because it acknowledges how modern applications actually want to work rather then pretending that server side rendering primitives have any relevance any more.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 13:17 UTC (Mon) by kskatrh (guest, #73410) [Link]

Something called X12 has existed for years and is entirely unrelated to X11 (http://www.x12.org/).

X, X11, X Window System were terrible names IMO, and if anyone was seriously developing a follow-on to X11 called X12 I'd say they were severely misguided.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 15:31 UTC (Fri) by Lennie (subscriber, #49641) [Link]

People use the same or similar names for different things:

http://en.wikipedia.org/wiki/X10_%28industry_standard%29

This is normal.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 20:14 UTC (Mon) by Corkscrew (guest, #65853) [Link]

> It probably was a bit tongue in cheek.

I'm not sure it was tongue in cheek. The impression I get is that the X community has a very entrenched focus on a particular group of power users. (For example all the commenters on here for whom network transparency is more important than tearing.) That makes it hard to effect major changes - you'll always be treading on someone's toes.

The only way to avoid being shouted down by this group is to essentially create a local fork of the *community* and pull resources (e.g. developers) across in a controlled fashion. In the absence of a meatspace version of Git, the easiest way to do this is to start an entirely new project, as this creates a barrier to entry for naysayers. Hence Wayland (and Mir for that matter).

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 21:17 UTC (Mon) by rahvin (guest, #16953) [Link]

The "fork" also allows people to keep using X until they are convinced that Wayland is appropriate for their workload. This is what bothers me so much about people that are up in arms about Wayland. X11 isn't going anywhere. It hasn't changed much in a decade and it will likely continue to not change much for the next decade.

If Wayland becomes popular at some point down the road you might need to switch to use some application BUT I'd be willing to bet that at that point whatever issue you have with Wayland will be mostly addressed (though you will never address the underlying assumption that client side drawing is better) or at least band-aided over to be tolerable.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:31 UTC (Tue) by nix (subscriber, #2304) [Link]

X11 isn't going anywhere --- but if people start targetting applications for Wayland, every single such application is an application I suddenly cannot run remotely with anything like the transport efficiency of X apps, particularly not if they are using anything for which GlyphSets would have been used (I don't really care if e.g. 3D games start to use Wayland).

And *that* is a loss of functionality. As mmarq has pointed out, Wayland only doesn't reduce functionality if *nobody targets it*. In which case its existence seems rather pointless.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 22:38 UTC (Tue) by marcH (subscriber, #57642) [Link]

> The impression I get is that the X community has a very entrenched focus on a particular group of power users. (For example all the commenters on here for whom network transparency is more important than tearing.)

... as opposed to the majority of "normal" users of the hugely popular Linux Desktop?

I doubt the power users have more than one girlfriend in average.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 13:50 UTC (Wed) by khim (subscriber, #9252) [Link]

... as opposed to the majority of "normal" users of the hugely popular Linux Desktop?

As opposed to the majority of "normal" users who don't use Linux Desktop (and increasingly don't use desktop at all). For these Wayland makes perfect sense... if you forget one tiny yet game-changing detail. Release date. Wayland released in 2003-2005 and then used in the "smartphones revolution" of 2007-2012 will be huge game changer. But it was not released neither in 2005 nor in 2007. Instead it was conceived in 2008 and released in the end of 2012.

Why "normal" users should use Wayland now when they have already made a different choice is enigma to me. I guess the hope at this point it to port Android (or may be BBX?) on top of Wayland - but I'm not seeing any movements in this direction.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 7:59 UTC (Tue) by mmarq (guest, #2332) [Link]

Delusions myfriend delusions...

Whatever follows what is being cocked wit OpenMAX infrastructure has a chance, else niche.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 0:17 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

"the movement to XCB is a slow one"

Whereas doubtless Wayland's designers have already shipped a complete working system and expect to have most of us seamlessly switched over to Wayland within say 12-18 months. No?

If these are the best arguments for Wayland, Wayland is in deep trouble.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 1:14 UTC (Sun) by Kit (guest, #55925) [Link]

This was more so a list of things about X that sucked, rather than X vs Wayland. Being Phoronix, though, you shouldn't expect the articles to be of the highest quality.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 7:09 UTC (Sun) by Creideiki (subscriber, #38747) [Link]

Daniel Stone made the same points much more in-depth at linux.conf.au 2013: http://mirror.linux.org.au/linux.conf.au/2013/ogv/The_rea... or https://www.youtube.com/watch?v=RIctzAQOe44

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 14:55 UTC (Mon) by drag (guest, #31333) [Link]

I can pretty much guarantee to you that in this case the authors of that article know a hell of a lot more about X Windows the you will ever.

It's a good move for them to write the article. Phoronix and related readers on Reddit are a source of much fud and bafflement related to X11/Wayland.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 3:51 UTC (Mon) by daniels (subscriber, #16193) [Link]

XCB has a lot of issues, such as being broken with various extensions (and some still not available, e.g. XI2), a deeply awkward API, and it took a long time to get proper interoperability with Xlib. All of these, plus having to essentially do a rewrite for not a huge amount of benefit (what with it being the same underlying window system and all), seriously hampered its adoption.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 15:42 UTC (Mon) by k8to (guest, #15413) [Link]

Is it deeply more awkward as compared to xlib? Serious question from someone who doesn't have a clue.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 11:27 UTC (Wed) by farnz (subscriber, #17727) [Link]

The difficulty with XCB (as compared with XLib) is that it exposes the request/response nature of X11 directly to the application.

For example, in XLib, if I want to find my parent window, I call XQueryTree(), which blocks me until the X server replies with all requested information.

To do the same with XCB, I need to use two of the window manipulation functions; I first call xcb_query_tree(), which returns a magic cookie. I then have to call xcb_query_tree_reply() to get at the result of my query tree operation.

This does give XCB two potential performance advantages when running over the network; the first is that I can often change my logic to send lots of requests, flush, then wait for the replies, which permits me to send larger network packets (as it sends all the requests in a minimum number of packets, rather than sending one packet for each request because XLib has blocked). The second is that I can hide latency; if I know that I'll need a reply in order to start processing the next iteration of a loop, I can send the request, do my processing for this iteration, then wait for the reply. For example, if I'm walking up the window tree and doing something at each level, I can code my loop as (pseudo-code):

analyse_parent_windows( connection, window, callback )
{
    parent_cookie = xcb_query_tree( connection, window );
    while( window != root_window )
    {
        reply = xcb_query_tree_reply( connection, parent_cookie, error );
        handle error;
        parent_cookie = xcb_query_tree( connection, reply.parent );
        callback( connection, reply.parent );
    }
}
This submits the request for the next parent while I'm still processing this window, and hopefully reduces the time I spend stalled waiting for X to reply. The equivalent done with XLib would have to wait after each query_tree operation for the X server to reply, resulting in lost time.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 21:02 UTC (Wed) by k8to (guest, #15413) [Link]

So just the usual extra work associated with nonblocking I/O, basically?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 16:21 UTC (Fri) by farnz (subscriber, #17727) [Link]

Pretty much that, plus some pain where XLib did multiple X roundtrips in one call (e.g. XQueryTree), and you now have to manage multiple request/reply pairs. There's also a small and shrinking area of pain where an extension is XLib-only, and you have to use XCB/XLib interop.

Additionally, the problems XCB fixes aren't visible if you do what most people do and use a local X server - they're only a pain if you want to use X over the network. So, for most developers, why port to XCB when you get easier, cleaner code with XLib?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 16:52 UTC (Fri) by dark (guest, #8483) [Link]

We might need a library that makes using XCB easier :) And I don't mean one that tries to be a layer on top (that would be libX11 all over again), but a library that provides tools for managing multiple related xcb calls, helpers for useful patterns like prefetching, and tons of convenience functions for common operations.

Unfortunately I probably wouldn't work on such a library because I'm not involved with any X11 based code anymore.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 15, 2013 1:32 UTC (Sat) by hummassa (guest, #307) [Link]

> We might need a library that makes using XCB easier

it's called Qt. :-D

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 10:31 UTC (Wed) by ovitters (guest, #27950) [Link]

Whereas doubtless Wayland's designers have already shipped a complete working system and expect to have most of us seamlessly switched over to Wayland within say 12-18 months. No?

Suggest reading development mailing lists. For Fedora: https://lists.fedoraproject.org/pipermail/devel/2013-March/180546.html.

So Fedora 19 has Wayland as alpha, 20 has it as beta, 21 as release.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 8:31 UTC (Sun) by marcH (subscriber, #57642) [Link]

Disclaimer: I do not understand anything about any technical details.

What I know is: at work we are supposed to use VNC but many of us use Xming instead (or Cygwin X).

The VNC / Remote Desktop / "desktop over desktop" user interface is completely broken. Two window managers on my screens? No thank you.

I've used remote X for as long as I've been using Unix. I do know how this works but it does work. I'm happy to believe that X11 is an unmaintainable engineer's nightmare fixed by Wayland. But if Wayland can't do remote X in some way then it's completely useless to every work place I've been to, big and small. And no I don't care a bit about fancy 3D graphics.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 9:36 UTC (Sun) by Frej (guest, #4165) [Link]

I've haven't used X/linux in years.. but it's quite simple to understand?
How do you come to the issue that must have multiple window managers? You you just assume it, and then you even state you don't know, and complain anyway. Not cool ;) Think of VNC as the abstract method of sending images vs. a protocol of drawing commands (Core X). Why does either method limit you of creating anything you need? Free your mind :-)

PS: You are probable using a crappy implementation of VNC (as in method) in remote X either way. As the drawing primitives by toolkits today consists of mostly sending images.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:15 UTC (Tue) by nix (subscriber, #2304) [Link]

I think of VNC as 'incredibly slow'. I have never used any implementation of VNC nor whatever the MS Terminal Server protocol is called that could scroll an Emacs window with text in it at more than about three to five screens per second, with a noticeable lag -- over a local network! And this applies to scrolls by one line as much as to scrolls by whole pages, which is a bit tough if you want to scroll up five or six lines, line-by-line, as I do quite often. Meanwhile under X, even remote X (over an Ethernet LAN) scrolling is latency-free: it scrolls so fast it is a blur.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 12:27 UTC (Sun) by cmrx64 (guest, #89304) [Link]

RDP and Spice both support "seamless" mode which has windows independantly floating around, not desktop-on-desktop.

As Eric says, nothing in Wayland precludes remoting equal to or better than X (it'd be better, because of the protocol's semantics). But nobody has implemented it yet, because they're working on other things.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 14:25 UTC (Sun) by mebrown (subscriber, #7960) [Link]

Why would you continue to make this criticism of Wayland when literally every single article (including the linked one) specifically says that they are working towards a solution for VNC/remoting, that the solutions are more technically elegant, and that there are already prototypes?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 16:20 UTC (Sun) by marcH (subscriber, #57642) [Link]

> Why would you continue to make this criticism of Wayland...

You are assuming that merely stating a (non-negotiable) requirement is a critic.

> they are working towards a solution for VNC/remoting, that the solutions are more technically elegant, and that there are already prototypes?

Here it comes again: the good, old and infamous "more technically elegant prototype". Thanks for answering your question yourself.

I have an old & ugly product that just works. Why the hell would I switch to an elegant prototype? I'm not an X11 engineer, I'm just an X11 LUSER. God preserves my favourite distro from switching.

I feel really sorry for the Wayland developers that X11 raised the user expectations that high.

I mean, come on: we are talking about an important feature here and not asking for some obscure and crazy backward compatibility hack
http://www.joelonsoftware.com/articles/APIWar.html

I like LWN. I pay for it. I love the technically accurate and insightful articles *and comments*. The only thing that I find sometimes annoying is the inability of a large number of people in this crowd here to think outside the engineer box and put themselves in the shoes of a plain luser who wants important features not to break and to Just Keep Working.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 16:39 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> I feel really sorry for the Wayland developers that X11 raised the user expectations that high.
In many cases Wayland developers _are_ X11 developers.

>I mean, come on: we are talking about an important feature here and not asking for some obscure and crazy backward compatibility hack
http://www.joelonsoftware.com/articles/APIWar.html
You're wrong on so many levels...

First, the old style X11 is not going away. It's going to be supported on Wayland for any foreseeable future, so you can "ssh -X" to your heart's delight in the next 10-something years.

Second, Wayland is not just something out of the blue. It's a logical evolution of real-world X11 usage patterns. It solves very real problems with X11.

Third, trying to preserve X11 will continue to make it more and more complicated and hard to support. Which will (at some point) make it impossible to add new features.

> put themselves in the shoes of a plain luser who wants important features not to break and to Just Keep Working.
They have. So X11 won't be broken. Your apps won't go away. Keep calm and continue working.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 21:05 UTC (Sun) by dig (guest, #91108) [Link]

Too many promises... X isn't easy peace of software, especially the one to emulate it on totally different concepts Wayland uses. Only the future will tell...

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 21:08 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

X on Wayland is easy. You just run a rootless server with a Wayland backend. Exactly as you would do it on Windows and Mac OS.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 8:28 UTC (Tue) by mmarq (guest, #2332) [Link]

So what is the point of Wayland ?

IF a dev codes for X, and he continues, wouldn't be much better to run it directly on X instead of a server on top of another ?

And yes i read all the arguments, but i see 2 trends developing for applications. One is Kronos the other is HSA, and they are some how very close related in many points.

Even Nvidia will eventually join(both) with their ARM push, and the same with Apple(LLVM is the dev base of HSA and Apple is LLVM). More dubious is Intel and Microsoft. The strength of X is not what lays ahead but the enormous baggage that lays behind... Why change ?... in a pure app POV what isn't broke don't fix it, the DS is *orthogonal*... so again why change ?

Is any of those DS , X, Wayland or Mir, going in the direction of the industry ?

(if i was an app dev right now, i would want it on Mac, Linux, Android and Windows etc... if possible... all this discussions and promises don't give me any incentive)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 17:18 UTC (Tue) by Tobu (subscriber, #24111) [Link]

Devs code for toolkits: SDL, Gtk, Qt, or even more high-level. One of the toolkits' jobs is to provide portability (though apps will use platform calls when the toolkits are weak on that front). I don't think a brand-new Kronos standard will displace them.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 22:04 UTC (Sun) by daniels (subscriber, #16193) [Link]

> X isn't easy peace of software

I know. And the only thing harder than doing X is continuing to shoehorn new features into it as it goes along.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 15:08 UTC (Mon) by drag (guest, #31333) [Link]

> Too many promises... X isn't easy peace of software, especially the one to emulate it on totally different concepts Wayland uses. Only the future will tell...

You don't know much about X then.

X11 runs perfectly well on many operating systems besides Linux. Windows and OS X are both examples that are supported by Xorg's Xservers. In fact one of the biggest contributors to Xorg is Apple and they use that code directly in their X11 related Apple products.

I find it extremely unlikely that Wayland will be much harder to support then Windows or OS X is.

In fact how Wayland is designed it should simplify the functionality of Xservers for Linux massively.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 15:33 UTC (Mon) by alankila (guest, #47141) [Link]

Hm. What X11 related products do Apple have now? They aren't even shipping an X server anymore.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 16:26 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Apple ships X server as a separate download. I'm using it extensively to run wireshark.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 16:46 UTC (Mon) by drag (guest, #31333) [Link]

Yep, http://support.apple.com/kb/ht5293

There isn't many people clamoring for X11 support in any OS except Linux (or the BSDs), but it does exist.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 22:49 UTC (Tue) by marcH (subscriber, #57642) [Link]

X servers with few applications, how come?

Because these servers are useful to run applications remotely of course.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 17:32 UTC (Sun) by tpo (subscriber, #25713) [Link]

> God preserves my favourite distro from switching

:-))) ! Thanks,
*t

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 9, 2013 21:16 UTC (Sun) by Mook (subscriber, #71173) [Link]

> Why would you continue to make this criticism of Wayland when literally every single article (including the linked one) specifically says that they are working towards a solution for VNC/remoting, that the solutions are more technically elegant, and that there are already prototypes?

Pretty much it keeps being described as a solution for VNC. From a user's point of view, VNC (/RFB) is horrible in that it is presented as a giant rectangular hole in which things show up, completely disconnected from the environment around it. In contrast, X can be forwarded without a root window so that things integrate well. If people start consistently describing the future Wayland solution without comparing it to VNC (even if it does do pixel scraping instead of sending drawing commands over), people like me will stop hating on it. As far as I can tell, this is the direction it's actually going anyway; it's just been a horrible communication problem because it's actually more VNC-like in a way that isn't quite as important to the user.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 1:21 UTC (Mon) by jzbiciak (guest, #5246) [Link]

Yeah, I cringe whenever I see the parallel to VNC brought up, because, as you point out, it makes all the wrong associations.

The VNC user experience sucks. And by that, I mean the end-to-end user experience of someone who fires up a VNC client and VNC server overtop of the existing windowing environments. The one where you get a window that behaves as a (crappy) monitor and doesn't integrate well at all with a desktop environment. (For example, getting tons of spurious "Cannot empty clipboard" errors in Excel on my Windows box whenever I leave something in the selection buffer on my remote VNC'd X connection.) Wayland, so far as I've read and understood it, does not seek to replicate that in any way.

Using communication model with async, timestamped requests and a focus on shipping bitmaps for windows instead of drawing primitives seems like a reasonable model these days for shipping a window from one machine to another. This model bears some resemblance to how VNC forwards an entire screen from one end to another, and keyboard/mouse inputs back the other way, but as I understand it, Wayland will just do this for individual windows.

Sounds entirely reasonable to me, and perhaps provide the best of both. Also sounds like it's less likely to hit snags, such as my fonts disagreeing between two machines leading to software looking weird.

I'm personally avoiding getting too excited (positive or negative) about Wayland until it gets to a point where it's worth it for me to give it a spin around the block, and that means finding it in a distro somewhere. I'm cautiously optimistic. I'm a little skeptical about some things, but I'm reserving judgment until later.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 9:16 UTC (Mon) by blackwood (guest, #44174) [Link]

Yeah, that's it. Wayland networking will combine the sound network protocol ideas of VNC (having a local server for the remote client and a local window on the local display server and forwarding bitmaps/input events asynchronously) with the nice integration of forwarding an X client. The end result is pretty impressive.

What's holding things up is simply that other stuff is currently a higher priority (like plugging the holes in the input layer for input methods and fleshing out the window display mode a bit). But I guess it'll all be in place when desktops environments have working Wayland code, together with XWayland and all the other pieces we need to have for a well-working full-fledged Wayland desktop.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:20 UTC (Tue) by nix (subscriber, #2304) [Link]

The end result is pretty impressive.
Except if you want to scroll windows full of text, since that means repainting the entire screen rather than erasing a line from the top, shuffling the rest up, and painting a line at the bottom (or vice versa), since it has no understanding of the semantics of scrolling.

I am told that in order to get such a rare and obscure use case to work I have to wait for toolkit-level remoting, which is as far as I can tell a complete mirage: nobody is working on it, nobody is planning to work on it, if people do work on it their work for distinct toolkits will be totally uncoordinated (natch), why aren't you happy with VNC-style bitmap shuffling nobody needs to scroll windows full of text anyway.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 19, 2013 0:14 UTC (Wed) by daniels (subscriber, #16193) [Link]

> Except if you want to scroll windows full of text, since that means repainting the entire screen rather than erasing a line from the top, shuffling the rest up, and painting a line at the bottom (or vice versa), since it has no understanding of the semantics of scrolling.

Again, this is completely false.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 13:21 UTC (Mon) by drag (guest, #31333) [Link]

> The VNC / Remote Desktop / "desktop over desktop" user interface is completely broken. Two window managers on my screens? No thank you.

There is absolutely no reason why you can't have individual applications remoted. If people want Wayland to be configured to be able to send individual display buffers over the network rather then a composited desktop then that should be very possible.

> I've used remote X for as long as I've been using Unix. I do know how this works but it does work.

It works sorta.

For your specific use case, really.

At my work we use a wide variety of remote desktop and remote application using Citrix and Windows and the idea that Linux/X11 is competitive with what you can accomplish using something like Microsoft Windows is ludicrous.

> I'm happy to believe that X11 is an unmaintainable engineer's nightmare fixed by Wayland. But if Wayland can't do remote X in some way then it's completely useless to every work place I've been to, big and small. And no I don't care a bit about fancy 3D graphics.

X11 can't even do what you _BELIEVE_ X11 can do. For most applications you really end up just shoving huge textures over the network similar to what people do with VNC, only much worse.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 14:35 UTC (Mon) by dps (guest, #5725) [Link]

Fortunately X can do better than that---I have run 3D X clients using *faster* on a remote server with better 3D acceleration (and more CPU and faster memory). Any ideas of making the remote client do software rendering on the slower remote system would be a huge step in the wrong direction.

NX takes doing work on the *server* side much further: it does extensive server side caching and has amazing performance other links with high latency and low bandwidth.

X has its faults but storing things on the server so things like cut paste between clients running on different boxes work is not one of them. Nor is allowing clients to actually use the acceleration available on the server.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 14:51 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

X provides very little remote support for any OpenGL feature past 1.5, and nobody seems especially interested in fixing that.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:22 UTC (Tue) by nix (subscriber, #2304) [Link]

Actually there have been suggestions (from Daniel Stone, IIRC) that might well get indirect GL working much much better with much less development overhead (IIRC the idea was to fall back to bitmap shuffling in situations in which you currently abort: yes, it's slower than hardware acceleration but at least it *works* and lets you do simple 3D stuff remotely which is just using it to do analogues of 2D-analogous stuff).

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 19, 2013 0:12 UTC (Wed) by daniels (subscriber, #16193) [Link]

I suggested to do the rendering locally. Very few GL-using apps (apparently I need to disclaim this now, so let me be clear that I don't think they're marginal or pointless; just not the majority) these days have heavier geometry usage than textures. It comes down to Blender/Maya/etc, and CAD apps really. At that point, bandwidth-wise, you end up sending more over the wire than you would just sending the final post-composed image.

Then the more significant hurdle is updating GLX beyond GL 1.5, which as others have noted, is a hell of a lot of work.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 10, 2013 14:58 UTC (Mon) by drag (guest, #31333) [Link]

> Fortunately X can do better than that---I have run 3D X clients using *faster* on a remote server with better 3D acceleration (and more CPU and faster memory). Any ideas of making the remote client do software rendering on the slower remote system would be a huge step in the wrong direction.

When the ability to get accelerated indirect rendering working on X I experimented with playing games over X11 protocol remotely.

It worked very well graphic-wise. But the controls were very laggy. So while the graphics rendered fast enough, the controls make it relatively unusable except under very ideal situations (ie: from one side of a lan to another)

Device and Network Independence

Posted Jun 10, 2013 10:48 UTC (Mon) by ortalo (guest, #4654) [Link]

For the sake of preserving LWN's commenters reputation on this topic, I thought we could extend even further than network independence concept for the goold old X13 display server, what about a windowing system that would offer device independence too?
Of course, for the sake of gamers, we may select GL/ES as the language instead of good old Postscript (but I'm still hesitating with the DVI command set for LNCS books reading). Let's have that Wayland *be* the toolkit server, the software that will unify Qt, GTK, DirectX and the like under a single rule (network independently of course.)

Device and Network Independence

Posted Jun 10, 2013 15:17 UTC (Mon) by drag (guest, #31333) [Link]

Wayland is actually the X11 dev's attempting to get out of the toolkit business once and for all. You can imaging GTK and QT as building on the X11 toolkit.

Instead of dictating methods on how Applications should be rendered (which X11 tries to do, and fails) all it cares about is the buffers produced by the application themselves. If the application wants to use OpenGL, DirectX, QT, GTK, or space monkeys with typewriters to render itself it makes little difference as far as Wayland is concerned, ideally.

Device and Network Independence

Posted Jun 11, 2013 8:39 UTC (Tue) by mmarq (guest, #2332) [Link]

Yes X11 could dictate that the window manger should handle it.

Consistent look & feel is important, and it could even use space monkeys. freedom is ok but anarchie is not

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 5:07 UTC (Tue) by russell (guest, #10458) [Link]

So when will we be using it as a default for distros? Last I heard weston was rejecting certain patches because it's just a testing ground. Does that mean every project is going to write there own version of weston? Sounds like we are starting all over again. Or did I mis-understand.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 13:02 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

It was the plan earlier, but Weston is definitely more than "just an example" now. Kinda like "nothing-serious-like-GNU" Linux.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 10:20 UTC (Wed) by ovitters (guest, #27950) [Link]

Don't rely on Phoronix for your news :P

GNOME shell will takeover some parts what Weston is doing AFAIK (+it was a logical thing to do). Making GNOME 3 fully work (on screen keyboard, accessibility, etc) will provide enough guidance on which things are lacking. Seems better to focus on the needs of current DEs (KDE, GNOME) rather than making another.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 10:39 UTC (Tue) by sorpigal (guest, #36106) [Link]

What I've gotten out of all of these Wayland vs X conversations is that there is a conceptual disagreement between people working on Wayland and just about everyone else concerning what "X replacement" really means. It seems to me that Wayland is not in the near term going to be an X replacement, instead it's just X plumbing. It's far too early to encourage toolkits and WMs to target Wayland directly for anything that can already be supported on top of X. The near future looks like rootless X on top of Wayland with applications (and users!) largely ignorant of the change; X plumping will have been replaced, but the protocol will still be in use and, from a user point of view, we will all still be using X. Whether there is any long-term move to targeting Wayland directly or whether some kind of X-successor emerges that wraps wayland is not something that seems worth worrying about just yet. The time to worry is when GNOME stops working if you don't have Wayland installed; it's only by that time that all these issues will have to have been worked out (and that time is not soon).

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 14:01 UTC (Tue) by butlerm (subscriber, #13312) [Link]

> It's far too early to encourage toolkits and WMs to target Wayland directly for anything that can already be supported on top of X

If toolkits can select X or Wayland at runtime depending on the environment, why wouldn't we want them to do just that? That appears to be (more or less) what the Qt Wayland folks are trying to do:

http://wayland.freedesktop.org/qt5.html

A similar effort is underway for GTK.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 11, 2013 15:45 UTC (Tue) by drago01 (subscriber, #50715) [Link]

GTK does the same. You can select the backend using an ENV var. It only works for apps that do not directly use xlib / xcb calls though.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 1:08 UTC (Wed) by butlerm (subscriber, #13312) [Link]

> It only works for apps that do not directly use xlib / xcb calls though.

Out of curiosity, what deficiencies of GTK/GDK would motivate a developer to do such a thing?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 1:49 UTC (Wed) by neilbrown (subscriber, #359) [Link]

It need not be deficiencies that would motivate such behaviour.

Suppose I wanted to write a soft keyboard. Drawing the keyboard responding to events could all be handled by GTK/GDK. But to actually send the keystroke events to the window with the focus, direct xlib/xcb calls would be needed.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 12, 2013 10:15 UTC (Wed) by ovitters (guest, #27950) [Link]

It's far too early to encourage toolkits and WMs to target Wayland directly for anything that can already be supported on top of X

Around 60% of the core GNOME modules already work under Wayland. The plan is a beta in GNOME 3.10, full support in GNOME 3.12. If a GTK 3.x+ application doesn't make specific X calls, it'll work under Wayland (devil is in the details :P). Firefox also finally seems to be going to GTK 3.x, though as they're huge, they might have various dependencies still assuming X.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 13, 2013 15:01 UTC (Thu) by Tobu (subscriber, #24111) [Link]

Is there a list of those modules? I didn't see Wayland in Gnome's CI thing.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 13, 2013 16:06 UTC (Thu) by ovitters (guest, #27950) [Link]

Almost all Wayland things are documented at https://live.gnome.org/Wayland. For the 60% bit I used https://live.gnome.org/Wayland/Applications 1-2 months ago. The count is "fixed"+"working" vs total (excluding "not checked"+"nothing to do"). This is a while ago. There used a be an issue with "subwindows". I noticed that more things work when you use "CLUTTER_BACKEND=wayland". If I check now, about 65% works, though some have working due to the environment variable and IMO more important that things might have a minor display issue than having the user set some environment variable. About 19% still a crash somewhere (=really bad!).

Suggest reading the wiki, because there are various things that really need to be implemented. Desktop environment is a bit more than just components.

conceptual disagreement between people working on Wayland

Posted Jun 13, 2013 13:39 UTC (Thu) by Wol (subscriber, #4433) [Link]

Given that pretty much the ENTIRE XFree86/Xorg development team have moved on to Wayland, I'd guess that your "everyone else" consists pretty much completely of people who don't understand what X is, so can't be relied on to know what an X replacement is, either ... :-)

Cheers,
Wol

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:35 UTC (Tue) by nix (subscriber, #2304) [Link]

I wish that was the case. But... if that was the case, Daniel Stone wouldn't be suggesting that people who use remote X are as important a use case as people who use xeyes.

With that sort of attitude, I have no confidence that remote Wayland will *ever* work properly. Clearly Daniel just has a laptop and does all his work on it, and damn everyone who uses more than one machine for anything.

Wayland explanations are STILL confusing and worrying users

Posted Jun 11, 2013 15:45 UTC (Tue) by david.a.wheeler (guest, #72896) [Link]

Daniel Stone emphasizes the problems of X, and is working to fix them with a new infrastructure. Sounds great! In particular, his outline of the PROBLEMS and why they happened are quite sensible. I look forward to trying out Wayland.

But I think Daniel Stone's effort to explain Wayland shows why users are so confused and concerned about Wayland. I think Daniel Stone's material is not clear to people who are not already steeped in Wayland. The problem isn't so much with Wayland. I think most explanations about Wayland - including this one - are confusing potential users, particularly regarding network transparency.

Daniel Stone says that "X is not network transparent". The problem is that this statement is obviously false. I routinely use X over a network with firefox, terminal, etc. So do lots of other people. We've done it for decades, and we plan to keep using network transparency. Statements like this make it appear that the Wayland developers don't understand X at all. Daniel Stone does understand X. I think what he means is that X is grossly inefficient over a network, in part because some extensions (shared memory, DRI-2, DRI-3000) are not network transparent, and in part because of all the synchronous requests that drive up latency. But statements that may be correct in a technical sense, but are clearly false to Joe User, are not helping the Wayland case. If he had simply said "X is very inefficient at network transparency, creating long unpredictable latency and complex programming" then it'd be easier to follow the point.

Regarding, "Wayland should be BETTER than X at remoting" - that may be true. But I didn't see in this text, or any other text, a commitment to actually implement remoting in Wayland. I think most users want to hear a commitment that Wayland will support network transparency in some manner - and all we hear is a statement of possibility.

So... whoever provides more facts about Wayland, please acknowledge that users (from the user's point of view) do get network transparency in X, explain why Wayland will do it better, and state a commitment that Wayland will implement remoting. The current text does not make that clear.

Wayland explanations are STILL confusing and worrying users

Posted Jun 11, 2013 17:05 UTC (Tue) by raven667 (subscriber, #5198) [Link]

It's the definition of "transparency" that is one thing that's tripping everyone up because while it might be easy to use, remote rendering is not actually transparent to the _application_, it has to know which rendering methods are available and needs to maintain two different code paths for shared-memory/DRI and remote rendering. As you point out modern toolkits tend to just produce fully rendered pixmaps and not use the Core X11 drawing primitives, so applications are reduced to just shuffling pixmaps around, inefficiently, for remote use.

Wayland explanations are STILL confusing and worrying users

Posted Jun 13, 2013 11:20 UTC (Thu) by sorpigal (guest, #36106) [Link]

I'll define "transparency" the way that it matters:

1. When I execute an application capable of displaying a GUI it appears on my local screen no matter what machine I am logged in to.

2. When I write a GUI application in the most naive possibly way it will work as described in (1) without me thinking about it during development.

If I write a GTK application today I don't have to put in a single line to get support for remoting (I don't have to plan for it) and if I run it on a remote system it displays locally without me, the user, having to configure anything. That's transparency. It's perfectly okay if the toolkit handles the hard work for me as long as it's easy enough that all toolkits are likely to include support.

Based on this definition:

Does Wayland support network transparency?

Is there a commitment by current Wayland developers to supporting network transparency?

But X can't do that ...

Posted Jun 13, 2013 13:48 UTC (Thu) by Wol (subscriber, #4433) [Link]

Not today anymore ...

Okay, I run KDE not Gnome, but the blame has been laid firmly at the feet of dbus - a Gnome innovation ...

The only way I have managed to get remote apps to work is to do a remote login and forward the entire session - any attempt to do a "DISPLAY=... command" just keels over.

And even that doesn't work over Cygwin - the login used to regularly fail half way through, and now if the screensaver cuts in I can never recover the desktop - I just have to close X and start again...

Cheers,
Wol

Works for me

Posted Jun 13, 2013 15:33 UTC (Thu) by david.a.wheeler (guest, #72896) [Link]

I routinely use X to access remote systems. So, it "works for me". Sorry it's not working for you.

Works for me

Posted Jun 26, 2013 6:21 UTC (Wed) by paulj (subscriber, #341) [Link]

Ditto.

Indeed, for me X works better than VNC, over a wifi connection that has OK latency but unreliable bandwidth. VNC is annoying to use over this, X is fine - you wouldn't know the window was a remote one using it!

But X can't do that ...

Posted Jun 13, 2013 17:42 UTC (Thu) by dlang (guest, #313) [Link]

Not all applications use DBUS

The fact that Desktop Environment authors seem to feel that every application, no matter how trivial should use DBUS is yet one more example of problems in that space.

But X can't do that ...

Posted Jun 14, 2013 14:22 UTC (Fri) by jschrod (subscriber, #1646) [Link]

I use KDE applications like kontact or similar on remote X displays routinely. Sorry that it doesn't work for you.

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 11:41 UTC (Tue) by nix (subscriber, #2304) [Link]

As you point out modern toolkits tend to just produce fully rendered pixmaps and not use the Core X11 drawing primitives, so applications are reduced to just shuffling pixmaps around, inefficiently, for remote use.
If they're using the render extension properly (which they are) this is an entirely inaccurate description of how textual regions are handled. The bitmaps comprising the textual glyphs are *not* sent repeatedly over and over again in repeated bitmap shuffles, but just once.

Wayland explanations are STILL confusing and worrying users

Posted Jun 11, 2013 23:06 UTC (Tue) by marcH (subscriber, #57642) [Link]

Finally someone who knows the technical details yet has respect for the stupid users who don't know and don't want to know them and who only want things to Just Keep Working without any regression. Thanks David, you never cease to impress me.

For lusers like me this is probably better reading than Phoronix' article then:

http://www.nomachine.com/documents/getting-started.php
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Com...

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 14:00 UTC (Fri) by mjthayer (guest, #39183) [Link]

> Daniel Stone says that "X is not network transparent". The problem is that this statement is obviously false. I routinely use X over a network with firefox, terminal, etc.

I wonder whether I am splitting hairs here, but is using X11 over ssh, which is what I presume most people here are talking about, technically the same thing as using X11 network transparency? ssh simulates a local X server and transparently proxies everything to an X server on a different machine, where it pretends that they are local clients. So from the point of view of server and client, everything looks like it is local, except that X11 features which cannot be proxied are not available.

Of course I don't know how easy it would be to do the same thing with Wayland. Presumably the Wayland protocol itself would not be a problem, but the proxy server would need at the least to track and proxy graphics buffer updates on the machine actually running the application, or alternatively intercept and proxy operations on them. The last might be tricky given that there are no restrictions on what interfaces can be used to access the buffers, but actually for most situations the first should be good enough. (I keep hearing noises about Kristian Høgsberg being working on something like this, but I haven't heard any about it being usable yet.)

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 15:29 UTC (Fri) by raven667 (subscriber, #5198) [Link]

The fact that application toolkits cannot have shared memory or IPC between clients is not transparent to them, they have to know about it and have alternate rendering to handle the remote display case. That's the hair splitting that is going on which is leading to confusion as you point out, toolkits already have these alternate rendering paths and with SSH tunnels the user experience is pretty good. As long as the user experience is good we should be able to make better technical decisions as to how it is accomplished than the way X does it.

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 18:07 UTC (Fri) by dlang (guest, #313) [Link]

> ssh simulates a local X server and transparently proxies everything to an X server on a different machine, where it pretends that they are local clients. So from the point of view of server and client, everything looks like it is local, except that X11 features which cannot be proxied are not available.

not quite

SSh forwarding does not simulate a local X server. It simulates a network X server running on localhost.

This is significantly different.

A local X server can use all sorts of shortcuts like shared memory for communication, while a network X server, even one talking to localhost, requires all the same infrastructure that you have to do true network transparency.

the Wayland interface is explicitly NOT able to be sent over a network, it requires local-only interfaces.

The suggested approach of using VNC is the situation where you have some process that simulates the display side and then ships the results elsewhere.

This is exactly the point that concerns so many people who routinely use the existing network transparency.

I remember running Quake over X in the late 90's, the only problem I had was that I hadn't bothered to try remoting the audio, so the sound came from the server two cubes over from me.

Saying that X is unusable for anything is just incorrect.

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 19:49 UTC (Fri) by mjthayer (guest, #39183) [Link]

>SSh forwarding does not simulate a local X server. It simulates a network X server running on localhost.

I stand corrected. Makes sense.

>the Wayland interface is explicitly NOT able to be sent over a network, it requires local-only interfaces.

I haven't looked at the protocol that closely, but what local-only interfaces does it need other than the small matter of the graphics buffers?

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 21:36 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Trying to deal with remote display at the hardware interface level where Wayland operates is probably not helpful, you could make a simple compositor which outputs to VNC but I'm sure we could do much better.

As is pointed out before, modern toolkits often use different rendering methods depending on whether they have local X (with shared memory, DRI) or remote X (serialized, sensitive to round trips), as well as for other platforms (Win32, OSX Quartz). Wayland support is provided by both a standardized protocol and a shared library which toolkits can use which is the canonical implementation of the protocol. The same approach should be taken for remote rendering, providing a standard protocol (maybe based on VNC or SPICE or including both wire formats) and a standard library implementing the protocol which toolkits can use. Then we could have real discussion on the best methods to implement a remote display protocol and what primitives should be made available for toolkit authors.

For example your toolkit, which I remind you can output on multiple type of platforms, knows which regions are scrollable, which are bitmaps, which are clickable, etc. so you can have an optimized, toolkit independent, way of remoting each region. Maybe you can pass compressed bitmaps directly and have them uncompressed on the remote end or cache text glyphs or pre-render scrollable areas. At the very least you can have some primitives that any toolkit can use to find their own clever ways to optimize for remove display.

I guess we need a team as passionate about remote display as the Wayland/X team is about local display. If the work is good enough it might even turn into a cross platform industry standard.

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 14:58 UTC (Fri) by daniels (subscriber, #16193) [Link]

Can I just be clear here - Eric wrote the article, I just fact-checked it and provided a few explanations to him. The wording and structure is all his.

X provides network support, if you go out of your way to ensure that you have performance worse than VNC/RDP, using APIs different to those you'd use for local rendering. And by 'you', I mean 'the toolkit used by your application'. In that sense, I don't believe that Wayland is conceptually much different.

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 18:10 UTC (Fri) by dlang (guest, #313) [Link]

why do you keep ignoring the people who state end give examples of uses where they get better performance from X than from VNC/RDP?

nobody disputes that there are cases where VNC/RDP do work better, but pretending in the face of specific examples that that is true for all cases hurts the credibility of Wayland.

Wayland explanations are STILL confusing and worrying users

Posted Jun 14, 2013 19:04 UTC (Fri) by daniels (subscriber, #16193) [Link]

Of course there are specific examples. xeyes and xedit will be better without bulk image transfer. Much like vim and irssi (which I use every day) are much faster over a remote shell protocol than either X11 or a bulk image transfer protocol. But, as I've said repeatedly, I'm talking about the vast majority (by usage) of apps and toolkits.

(And hey, if that's bothering you, why? XWayland continues to exist as a first-class solution. Just do remote forwarding to that.)

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 11:51 UTC (Tue) by nix (subscriber, #2304) [Link]

Well, I just hope that text editors forever continue to target X rather than paying the least attention to Wayland, then, since you don't care about text editors.

FWIW, with the exception of a bunch of molecular modellers almost the only people I have ever seen use X in anger outside Linux distributors, and the only people I have ever seen use remote X routinely, have used it overwhelmingly for... text editing! In fact this is a majority use case for *all* computers used in work environments, if you include word processors and spreadsheets, which will suffer the same scroll-related problems as text editors if run remotely over anything implemented via bitmap-hurling.

But you don't care about that, as you have made abundantly clear by comparing those of us who care about remote use of such applications to people using xeyes. I'm not sure what use cases you *do* care about, if text editors and word processors and spreadsheets are all excluded. It doesn't leave much except for video playback and web browsers, and if you only want to use *those* you might as well use a tablet these days.

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 12:09 UTC (Tue) by daniels (subscriber, #16193) [Link]

Kristian's rolling-hash implementation of remote Wayland is _specifically designed_ for scrolling content, be it text or images. Have a look at:
http://people.freedesktop.org/~krh/rolling-hash/f8.png
http://people.freedesktop.org/~krh/rolling-hash/f9.png
http://people.freedesktop.org/~krh/rolling-hash/f8-f9-deb...

And then come back and tell me again how no-one working on Wayland cares about terminals, text editors, or scrolling text.

How you've taken from me saying that the overwhelming majority of my day is spent in vim, irssi, Evolution, Evince, or Chrome scrolling huge chunks of text, that I don't care about scrolling text, is honestly beyond me. I'm not comparing scrolling text to xeyes either: I'm saying that even X11 isn't a very efficient protocol for scrolling text, because oddly enough the most efficient protocol for doing that is text-based. Like SSH. Just as X11 is the most efficient protocol for transferring X11 primitives.

I'm done arguing with people who have constructed strawman motives for a strawman protocol, neither of which bear any resemblance whatsoever to reality.

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 13:09 UTC (Tue) by nix (subscriber, #2304) [Link]

Awesome!

Why on earth didn't you just say that to start with rather than going all sarcastic and contemptuous? All I said was that I couldn't think of an implementation -- that doesn't mean there isn't one.

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 13:57 UTC (Tue) by daniels (subscriber, #16193) [Link]

I've said it over and over, repeatedly, time after time, in the comments here. But unfortunately people insist on ascribing motivations we don't have to us, while critiquing a design which doesn't exist. Gets pretty tiring after a while, to be told neither myself or Kristian care about text, which is why the hypothetical design the internet has collectively made up for Wayland remoting (despite pointers to the actual design) is deficient. Really, really tiring.

Wayland explanations are STILL confusing and worrying users

Posted Jun 25, 2013 20:31 UTC (Tue) by nix (subscriber, #2304) [Link]

That's what happens when you implement impossible magic. People don't realise it could possibly work, so assume it doesn't. :)

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 13:11 UTC (Tue) by nix (subscriber, #2304) [Link]

Kristian's rolling-hash implementation
Oof. So you're still analyzing bitmaps on every scroll to determine that they consist of scrolled text. Cache-ruinous compared to what is currently done. Oh well, at least you're not throwing them over the network.

Wayland explanations are STILL confusing and worrying users

Posted Jun 17, 2013 11:44 UTC (Mon) by nye (guest, #51576) [Link]

>nobody disputes that there are cases where VNC/RDP do work better

It's not fair to say VNC/RDP, as if they're similar, when RDP is really more like X than it is like VNC.

It will ship rendered bitmaps over the wire if necessary, but it should only be necessary in the case that the client has done its own rendering into a bitmap, where X would need to do the same.

The experience of using RDP is vastly better than VNC in pretty much all cases, and at least somewhat better than X in the grand majority of cases.

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 20:52 UTC (Tue) by foom (subscriber, #14868) [Link]

Well, those parts of RDP are nearly dead now. These days windows does basically all rendering on the host side (including 3D), and sends bitmaps to the client. Even fonts are rendered on the host side, ever since ClearType has been used.

The main exception to that strategy is that desktop compositing does get done on the client via dedicated compositor commands.

The experience of RDP *is* vastly better than VNC, but that's not because it's using primitive drawing commands -- that strategy stopped working out very well years ago.

Wayland explanations are STILL confusing and worrying users

Posted Jun 19, 2013 11:52 UTC (Wed) by nye (guest, #51576) [Link]

>The experience of RDP *is* vastly better than VNC, but that's not because it's using primitive drawing commands -- that strategy stopped working out very well years ago.

True, applications aren't requesting that the windowing system draw a line segment from A to B, and so on, but in practice X11 applications aren't doing that either.

There is a middle ground in between basic line-drawing primitives and bitmap scraping. RDP does typically work at a higher level than screen scraping, which is why nix's example of scrolling a text editor sounds highly suspect - I've just tried connecting to a Windows desktop (via whatever mechanism Remmina uses for rdp; I guess it wraps rdesktop), opening a large-ish file in gVim, and scrolling both casually line-by-line and madly by mashing page down. It's just as fast and responsive as running vim in an xterm over the same link[0] (ping ~45ms), and in fact seems to have slightly less input lag. Notably, looking at the data transferred, RDP is using a fair bit *less* bandwidth.

The point is that VNC is not comparable to this. It very clearly has to resend large amounts of data for even single line scrolls; it doesn't work in the same way at all.

With any luck Wayland's remoting will sit at a similar point to RDP on the primitives<->scraping spectrum, and everything will be rainbows and unicorns.

[0] That is, 'ssh -X <host> xterm vim'. For a more direct comparison, I did try 'ssh -X <host> gvim', but that really wasn't a fair comparison since X is useless over WAN links. The bandwidth requirement was higher still, and the input latency was so high that nobody could seriously consider it usable in any but the most desperate of circumstances. If you are only ever moving line-by-line, then it would win over VNC, but if you ever want to scroll a whole screenful it takes a similar amount of time.

Wayland explanations are STILL confusing and worrying users

Posted Jun 19, 2013 13:05 UTC (Wed) by Jonno (subscriber, #49613) [Link]

> There is a middle ground in between basic line-drawing primitives and bitmap scraping. RDP does typically work at a higher level than screen scraping
> The point is that VNC is not comparable to this. It very clearly has to resend large amounts of data for even single line scrolls; it doesn't work in the same way at all.

Actually, the VNC *protocol* are fully capable of efficient scrolling, but most VNC server *implementations* work by doing screen scraping and don't have any heuristics to detect scrolling, thus resulting in terrible performance. The Wayland reference implementation is a lot better in this regard, and performs much better than what is typical for VNC, even though it uses the same design principles.

Also worth noting is that the Weston reference implementation actually uses the RDP protocol, which btw also uses the same design principles as VNC.

So if you compare a typical VNC implementation and the Windows RDP implementation, the Weston implementation should be closer to the later, as the server sits at the same position in the graphics stack *and* uses the same wire protocol (though implementation differences will of course make some impact).

Wayland explanations are STILL confusing and worrying users

Posted Jun 19, 2013 13:56 UTC (Wed) by nye (guest, #51576) [Link]

>Actually, the VNC *protocol* are fully capable of efficient scrolling, but most VNC server *implementations* work by doing screen scraping and don't have any heuristics to detect scrolling, thus resulting in terrible performance.

Now *that* is interesting information. Perhaps I'm reading too much into your choice of the word 'most', but does that mean you know of VNC servers which are better in this regard? And do they require a matching client?

Wayland explanations are STILL confusing and worrying users

Posted Jun 19, 2013 14:47 UTC (Wed) by raven667 (subscriber, #5198) [Link]

I wonder how the OSX client/server rate, in my experience the pair is very good but VNC performance using another client is poor. It may be using these optimizations because performance is fairly good. Scrolling terminals isn't slow.

Wayland explanations are STILL confusing and worrying users

Posted Jun 19, 2013 15:28 UTC (Wed) by Jonno (subscriber, #49613) [Link]

> Perhaps I'm reading too much into your choice of the word 'most', but does that mean you know of VNC servers which are better in this regard?
Most VNC servers make some use of the protocol feature (i.e. for window movement on the virtual desktop), but to my knowledge no X11-based VNC server is capable of automatically using the feature when scrolling part of a window.

That said, libVNCServer makes it available to custom applications, and x11vnc has an experimental command line option to try to detect scrolling in the frames it scrapes from the X11 server.

> And do they require a matching client?
The "CopyRect" image encoding is one of the five original encodings of the specification, but only the "Raw" image encoding (uncompressed bitmap data) is mandated, everything else is negotiated per session. So while most clients support it, some might not.

Wayland explanations are STILL confusing and worrying users

Posted Jun 25, 2013 20:32 UTC (Tue) by nix (subscriber, #2304) [Link]

Note that my example was from back when I was doing that sort of thing, which was 2010-era and older, and god only knows how old the RDP backend I was talking to was. They probably have improved in the meantime.

Wayland explanations are STILL confusing and worrying users

Posted Jun 18, 2013 11:39 UTC (Tue) by nix (subscriber, #2304) [Link]

Regarding, "Wayland should be BETTER than X at remoting" - that may be true. But I didn't see in this text, or any other text, a commitment to actually implement remoting in Wayland. I think most users want to hear a commitment that Wayland will support network transparency in some manner - and all we hear is a statement of possibility.
Yes. This.

(It's not as if my 'run on a remote box with graphical output in a local window, scroll text efficiently in that window, allow disconnection and complete powerdown of the local machine without breaking the remote client' use case should be incredibly difficult, either. Heck, X could do all of that in the mid-to-late 80s!)

Wayland explanations are STILL confusing and worrying users

Posted Jun 19, 2013 7:14 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> complete powerdown of the local machine without breaking the remote client

Other than Emacs, what apps actually support this? For me, every time the SSH connection does, anything that used X over it dies.

Wayland explanations are STILL confusing and worrying users

Posted Jun 25, 2013 20:38 UTC (Tue) by nix (subscriber, #2304) [Link]

I've used a couple, or seen others use them. Mostly big simulation apps with lots and lots of state. These days, one would probably write a server and a frontend with less state... but that happened not to be how those were written.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 13, 2013 0:19 UTC (Thu) by amarao (guest, #87073) [Link]

I don't know about cool part of X server, but the basic part for remote application execution (I mean local X server, remote application) is still very valuable feature. Some not-so-nice vendors creates craphic management software for servers. It much comfortable to run them via ssh (ssh -XYC application) than install vncserver and all X-related stuff to the server.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 13, 2013 16:40 UTC (Thu) by ajmacleod (guest, #1729) [Link]

More of the same hype and FUD which I find very tiresome indeed. Wayland is held up as some kind of saviour which is going to fix everything in the *nix display world and be far better than X in every way.

I hate this baby-out-with-the-bathwater attitude which seems to be infecting the free software world; we're expected to hail the new wonder child as our saviour who promises to do all kinds of things better when in fact it _does not_ and might well never do.

Maybe Wayland will be everything that X is now and better... I'll believe it when I see the proof and will be sad if, as I suspect, that day never comes but X is reduced to unsupported abandonware and we have to live with something actually less useful.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 6:33 UTC (Fri) by micka (subscriber, #38720) [Link]

> if, as I suspect, that day never comes but X is reduced to unsupported abandonware and we have to live with something actually less useful

or "just" take over maintenance of X when it's abandoned.That should be easy, right ?

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 13:33 UTC (Fri) by ajmacleod (guest, #1729) [Link]

No - because by that point some of the most useful applications will depend on some Wayland feature and so there won't be a lot of point in maintaining X; we'll be more or less forced to live with Wayland whether or not it's better.

Note that I _hope_ this doesn't happen and that Wayland really does do everything X does but better... I just don't like the way it's been pushed so far, it brings to mind gnome 3 and Windows 8 / Metro amongst others...

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 14:09 UTC (Fri) by micka (subscriber, #38720) [Link]

> by that point some of the most useful applications will depend on some Wayland feature

Programs mostly use Qt/GTK/EFL and OpenGL or things like SDL. Those are the parts that decide if an application is compatible with a display infrastructure (X, Wayland,... well, even Mir).

Your program looses compatibility with X when the library you use does. Some are built so that the display backend can be choosen at runtime. From what I see, one backend will be deleted with a commit message like "this has been broken for two years and nobody even noticed".

I expect Xwayland to keep working for a very long time. I hope because I still hope to play the handful of linux native games I own.

Of course, compatibility is never an easy thing. You *can* expect things to break from time to time if nobody tests and reports less used backends.

> it brings to mind gnome 3 and Windows 8 / Metro

Different things.
Gnome3/Metro are (AFAIK, I never used Metro) user interface and user visible changes.
X->Wayland is a technical change. The user should be (ideally) presented exactly the same UI with Wayland that it was with X.
There will be minor (for the user) changes, like the way screensavers/screenlock and screenshot functionalities are exepcted to change, but apart that, the user should not see anything different (except early adopter, those who test, report etc.)

Yes, I'm aware of my heavy use of "should" :)

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 19, 2013 0:23 UTC (Wed) by daniels (subscriber, #16193) [Link]

I think anyone would be hard pressed to call it 'throw[ing] the baby out with the bathwater'.

In the 26 years since X11's initial release, it's gained multi-output support (four times), multi-input-device support (three times), hotplugging for both, a new keyboard model, a compositing model, a new rendering model, direct OpenGL rendering support (twice), indirect OpenGL rendering, accelerated indirect OpenGL rendering, a new font rendering model including anti-aliasing (three-ish times), autoconfiguration support, an acceleration architecture (four-ish times), Display PostScript support (later removed), a print server (also later removed, thank god), and has been ported to everything from mobile phones to renderfarms.

So how you can essentially accuse us of not having trying, and done this frivolously, is beyond me.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 20, 2013 13:54 UTC (Thu) by ajmacleod (guest, #1729) [Link]

I didn't accuse anyone of "not trying"; I've said repeatedly that I hope Wayland does do everything X is actually used for today and does it better. I'm just a bit weary of a particular type of approach which seems quite common at the moment where a replacement for some piece of technology is wheeled out at the barely usable prototype stage, claimed to be the one true way with all that went before being completely broken and to be abandoned... while the replacement doesn't actually DO everything that its predecessor did.

Nobody has claimed that X is perfect, but I do claim that it does absolutely everything I want it to do, does it without any fuss and has done so for a decade and a half (over which time the things I've been actually using it for have changed quite a bit.) Remote X display has never, ever been a "nightmare" for me, or for anyone I know - frankly I've always considered it verging on the miraculous! If X has problems, which I'm not disputing, they're at a level where _users_ don't see them. I wish the Wayland developers all the best, and if they can make it all work as well and transparently as X currently does I'll be very happy!

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 20, 2013 15:34 UTC (Thu) by raven667 (subscriber, #5198) [Link]

This is all worth highlighting and is a gem of this discussion.

> technology is wheeled out at the barely usable prototype stage, claimed to be the one true way with all that went before being completely broken and to be abandoned

Some of that is just a consequence of open development, by definition you have the software before it is in a "finished" state, and see the dark corners as it is being made. Often the software isn't really "done" or "ready" until after several iterations of release, sometimes spanning years, and everyone has to suffer through the iterations until it works the way it should. See GNOME 2 and GNOME 3, they really didn't get into their stride with feature completeness until after the .8 or .10 release.

> completely broken and to be abandoned... while the replacement doesn't actually DO everything that its predecessor did

Some times things are replaced without knowing why the old thing did the things it did, google "mjg59 lighdm" for a good example of that. Unfortunately there sometimes isn't enough manpower for parallel development and maintenance.

> Remote X display has never, ever been a "nightmare" for me, or for anyone I know - frankly I've always considered it verging on the miraculous! If X has problems, which I'm not disputing, they're at a level where _users_ don't see them

And that is due to the very hard work of people like Keith Packard and Daniel Stone and all the X.org team. They have busted their butts over the years trying to make X not suck so that you and I could be blissfully unaware of the contortions and brokenness behind the scenes. It's a testament to their success and hard work that people don't believe them when they say that X11 is fundamentally broken.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 13, 2013 19:25 UTC (Thu) by Fats (guest, #14882) [Link]

Next to network transparency that should/could be better on Wayland but without a commitment of implementing it I have another big worry.
When I last delved into this it was up to the clients to move their own windows, minimize/maximize them, etc. So when the client is busy with something else you can't move it's windows. Let me tell you this is one the Windows 'features' I hated most. Is this fixed in the mean time for Wayland ?
Maybe this is needed for this having the 'display right all the time'. But if I have to choose between windows movable at all times or flicker/lag free display at all time, I'll choose movable at all times without a wink.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 6:36 UTC (Fri) by micka (subscriber, #38720) [Link]

>When I last delved into this it was up to the clients to move their own windows

If I remember correctly, it's a choice that's made at the compositor level. For example, I think that for Kwin (the compositor), window management will not be done by the client.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 8:56 UTC (Fri) by renox (guest, #23785) [Link]

>When I last delved into this it was up to the clients to move their own windows

No, I made a similar mistake but this is wrong..
What happen is: when you click on the tittle-bar, the client recognize that you want to move its window and it asks the compositor to put the window in a "move mode": then when you move your mouse the compositor will move your window without the client being involved.
So 1) moving window will be smooth(done entirely server side) once the 'move mode' has started
2) if the client is busy then yes, you can't move its windows, but as the compositor ping continuously the clients, it can detect frozen window and "takeover" the window management.

Things are different for resizing where indeed you have the trade-off you describe, and as you said with Weston resizing is made by the client so every frame will be "perfect" BUT if the client is slow/busy then the resizing will be jerky/lagging (you move your pointer but the window doesn't resize until the client catch up).

IMHO this isn't very good here, like you, if a client is slow/busy I prefer that resizing its window has smooth resizing of the outline even if the content can become "ugly" (when the client fails to provide the content in time) to 'perfect frame' but with jerky/lagging.
Ideally we would use BeOS-like multithreaded clients which would never be slow/busy but in the meantime the trade-off is here..

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 14, 2013 14:25 UTC (Fri) by mjthayer (guest, #39183) [Link]

>>When I last delved into this it was up to the clients to move their own windows

>No, I made a similar mistake but this is wrong..
>What happen is: when you click on the tittle-bar, the client recognize that you want to move its window and it asks the compositor to put the window in a "move mode": then when you move your mouse the compositor will move your window without the client being involved.

I seem to recall hearing something about the client informing the window manager in advance about which areas of the window could be used for dragging, so that it would work even if the client was not responsive. I might be wrong though.

>IMHO this isn't very good here, like you, if a client is slow/busy I prefer that resizing its window has smooth resizing of the outline even if the content can become "ugly" (when the client fails to provide the content in time) to 'perfect frame' but with jerky/lagging.

I have to say that I actually prefer resizing to be the client's business, having seen enough cases of the window manager and client mis-co-ordinating that. In extreme cases the window manager could still clip the client.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 11:56 UTC (Tue) by nix (subscriber, #2304) [Link]

as the compositor ping continuously the clients
Isn't that rather bad for power management?

One hopes that it actually pings clients which should have an event directed to them when such an event turns up, which would add no overhead and have the same effect of detecting slow or unresponsive clients reasonably rapidly.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 12:43 UTC (Tue) by renox (guest, #23785) [Link]

Weston being a prototype, I'm not sure that they worried about power management in their implementation especially as the protocol is the same in both cases.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 18, 2013 13:09 UTC (Tue) by nix (subscriber, #2304) [Link]

Yeah, that's what I expected. Of course prototypes turn into production implementations all the time :P

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 19, 2013 0:24 UTC (Wed) by daniels (subscriber, #16193) [Link]

> One hopes that it actually pings clients which should have an event directed to them when such an event turns up, which would add no overhead and have the same effect of detecting slow or unresponsive clients reasonably rapidly.

It does.

The Wayland Situation: Facts About X vs. Wayland (Phoronix)

Posted Jun 25, 2013 20:37 UTC (Tue) by nix (subscriber, #2304) [Link]

Good design, then. Unlike certain other programs I could mention (yes, mongodb, of *course* you should wake up a hundred times a second when idle because select() is too hard to use properly, sigh.)


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds