Wayland 1.0 Released, Not Yet Ready To Replace X11

An anonymous reader writes "After being talked about for four years, Wayland 1.0 was released today. The Wayland 1.0 release doesn't mark it yet as being ready for Linux desktop usage but just being API/protocol stable for future expansion. Wayland will now maintain backwards compatibility going forward, but how much longer will it take to replace X11 on the Linux desktop? Quite a while seems likely."

Comments

Re:Hopefully another 25 years or more

[Anonymous Coward]

Unfortunately, developers are the second worst group for understanding what users need. The only part of X11 that people need is network transparent remote display, but that's the one part that the developers are absolutely hell bent on removing.

Application and Screen on Different Machines

[billstewart]

The important feature about X Windows was Network Transparency - You could run an application on one computer with its screen output and keyboard and mouse input on a different computer. Sure, there are other ways to do it - lots of ssh sessions, or web browsing (especially with AJAX etc.), or competing window systems like NeWS, or screen emulators like VNC and Windows Remote Desktop - but fundamentally it's a lot cleaner to have some kind of network-transparent window system than to have an application need to drive a "screen" on its own machine.

25 years later, do we still need this? Yes! Virtual machines are taking over the computer business, so you can't expect the application to be running on your desktop (even if it _is_ running in a VM on top of your desktop), screens are a wide range of different sizes and capabilities (laptops, tablets, big monitors, etc., which often don't resemble the machine the app is running on), web browsers are getting used in increasingly complex ways because Windows didn't have a convenient X interface, and there's more and more ugliness around, and more waste of resources trying to emulate things that X did adequately well.

There are lots of good reasons to replace X, but Network Transparency is still the core feature, even if you want the application to have more control over the screen and its associated hardware than we had back in the 1980s, or if you want to move processing functions to different points between the client and the server (e.g. NeWS and NeXT's Display Postscript did some things differently, and Plan 9 and its successors had their own opinions about how to implement everything), but if Wayland doesn't offer Network Transparency yet, it's not an adequate X replacement.

Re:Application and Screen on Different Machines

[Anonymous Coward]

Speak for yourself. I was just using the 'network transparency' features of X the other day, as well as NAS (Network Audio System) and going 'thank god this made it so easy!'

Literally all you had to do was have the nasd daemon running on the client and fire up the app on the server. Same deal with X. I was able to spit out my app with full audio across the network. I wouldn't want to try Quake or something over it, but I'm sure that given some work on X11 and 10G ethernet I could probably do that as well.

Honestly my problems at the moment are less with Wayland and more with them constantly fucking things up on the X11 front with the incessant streams of changes and deprecated features. In order to run MESA now you have to have a c++ compiler, and can't use any hardware other than Intel, AMD, or Nvidia (via nouveau) since all have been deprecated due to the removal of DRI1. Additionally despite YEARS of opportunity, there's still no inline way to have apps change display resolutions, so for those of us with 8/16 bit games we can't just fire them up, we have to run them in a dedicated 8 or 16 bit color X server, which oh by the way the latter doesn't work on any supported 3d hardware (MAYBE MAYBE R100/R200, although bother of those drivers are somewhat unreliable nowadays), and oh by the way we broke 8 bit palette support, so the former is in greyscale even on color displays (I ran into this after upgrading X on one of my laptops with an IGP345 on it. Horribly slow at 16/32 bit color, but with lots of 8 bit apps that'll run smooth).

It's not wayland that's FUBAR, it's how they've been handling X for the past however many years that is. They keep talking about 'improving' on X, but they can't even keep X displaying the same features it had 10 years ago due to inadequate testing, so what do you expect them to do in another 5 years when wayland is really 'mature'? Break more shit because it didn't matter to them and tack on new crap you don't care about.

That's just my 2c as an X user since the late 90s, having followed Utah-GLX, the starting of Mesa, The XF86/Xorg schism, and all the BS since.

Re:Application and Screen on Different Machines

[oursland]

Hi Bill,

You have a good point, but unfortunately the X system is fundamentally flawed at the technical level for the purpose you describe. When X was originally developed, graphics were simple aliased lines and bitmapped fonts. In the modern computer environment, this has presented itself as a grave hindrance to the usability of X.

Modern applications depend on graphics toolkits, such as GTK and Qt, which render in to X pixbufs and finally those are rendered on the display. The process by which this happens depends upon copying these toolkit-rendered images from buffer to buffer several times, quite needlessly to fit within the X framework. This is moreso true over a network connection. The very nature of modern programs has progressed way beyond what X was intended and optimized for. It is like trying to use a MUD infrastructure designed for textual interaction as the basis of a modern GUI framework, it simply isn't the right tool for the job.

An anecdote, this weekend I decided I was going to work from home. So I ssh into my work computer (6 miles, 20+ Mbps connection), and fire up an X forwarded my graphical editor session. Things were slow, but not unusable until I did something that caused a series of tooltips to be rendered. The session locked up for 2 minutes before I killed it. I then fired up a terminal-based text editor and got to work. X's network transparency was not beneficial. But there are many network protocols that have been designed for the purpose of remotely operating modern GUI applications such as VNC and RDP. These have been designed from the ground up to provide the functionality we expect on today's systems.

And before I finish my tirade, I, too, was a die-hard X fan until I decided to see what the Xorg folks had to say. Keith Packard (a lead developer on Xorg, inventor of Cairo and much more that you depend on when you fire up your workstation), has been a hard proponent of Wayland. He's given many talks outlining the design failings of X and how Wayland resolves them. I recommend you google "Keith Packard Wayland" and see what you find.

Regards,
oursland

Re:How long?

[whoever57]

Every time Wayland comes up, people come out of the woodwork to declare it a failure because it won't run over a network, but that's the only real gripe I've seen. You say there are others, I'm curious to know what they are.

Network transparency is very useful for administering servers. It is very useful to run the various GUI programs that I run on various servers on our office network. Wayland supporters have suggested using VNC for that, but it misses the point, since that implies one VNC session per remote machine, which means multiple VNC sessions, each with its own window manager, issues with copying and pasting, etc..

The other key advantage that X11 has: if the application is mis-behaving the application's window can still be controlled by the window manager. Ever seen windows on a Windows desktop that cannot be minimized? Wayland is bringing that to Linux.

Re:Hopefully another 25 years or more

[tqk]

I guess all of the X11 developers that are the ones developing Wayland don't understand X11 that well.

"Don't understand X11 that well", I don't know (though I'd doubt they don't understand X). As for whether X11 needs replacing; not here, no.

I do worry that they're ignoring the ideals of X, and focusing too much on cellphone/*pad interfaces, as opposed to the original X ideal (any device *should* be able to handle it, regardless of what your particular prejudices might be).

Does Fluxbox run on Wayland? If so, I'll try it.

Re:what about xorg?

[serviscope_minor]

The deal is that the way of rendering that both X11 and windows GDI support is 20 years behind the times.

So?

I hear this a lot. The thing is, the code might have been large and complex 25 years ago when X11 was new. The code hasn't grown. By modern standards it's small and simple. And if it's rarely used, then it will sit on disk un-paged and never getting in the way. Actually with the removal of many things which used to be but no longer are optimizations it's shrunk.

Rarely used code does not affect performance.

Nobody renders like that.

I'm going to keep using xterm thanks. And I'd appreciate if you didn't make false claims about me.

These days the X server doesn't support the primitives the application designers need, because to do so would mean reimplementing, for example, a path based compositing renderer.

Firstly, X11 does support basic compositing now, and has for a while. Secondly, what's with the claim about "reimplementing"? One could easily make a cairo-x11 extension. In fact there used to be a x11-DPS extension so it's clearly possible.

The legacy APIs are useless, they don't scale anymore.

[citation needed]

Anyway WHO CARES? Modern toolkits don't use the "legacy" APIs and old programs aren't big. So it's all happy and nice.

IOW, if you code to X or GDI APIs, your application will perform poorly and there's no way for something on the implementation side of the API to fix it for you.

Your claim is something like 20 years out of date. X11 has had a standardised interface to hardware accelerated OpenGL since before PCs even had 3D cards. Most people don't and didn't use it because even the "poorly performing" "legacy" APIs are entirely fine for almost all programs which sit there doing nothing until a key is pressed.

When designing an application of any sort, the graphics API needs to present primitives and abstractions that translate well into efficient uses of graphics hardware. I'm sure people who deal with accelerating modern frameworks like Qt will tell you all there's to know about how broken the legacy API is when faced with modern hardware.

Well, yes, but then again. they probably don't use "legacy" APIs, prefering to use things like XComposite, XFixes and so on and so forth.

Basically, the X11 prorocol is really well designed, upgradeable and does a lot of things very well. One part of it (the original drawing protocol) was basically due for a major upgrade. That partly happened with XComposite and off-screen rendering. It could (and probably should) be continued with a higher level (e.g. SVG) drawing protocol.

Other parts of the X11 protocol have aged very gracefully, and are still very good.

Missunderstanding the issues

[Trevelyan]

The two main complaints I see discussed here appear to derive from some fundamental misunderstandings about what Wayland is.

Wayland is a Protocol and an optional helper library to implementing that protocol. This protocol says nothing about net work transparency, in both the sense of enabling or prohibiting it. It also says nothing about client decorations. The key points here is not to make a decision for or against any particular technology or methodology and then be stuck with that decision for the next 20 years, like we are with X.

How or if, either of these work is all down to the compositor. The reference compositor 'Weston' does not do network transparency and leaves window decoration to the client or its toolkit. However none of the big desktops, i.e end users, will be using this compositor. For example KDE will continue to use Kwin as their wayland compositor, and KDE have already clearly said that Kwin will be decorating their windows and not the clients!

As to network transparency, all windows are drawn to their own back buffers, and where these buffers will be eventually displayed is also the choice of the compositor, and it might well just decided to send them over a network connection. e.g. like what VNC does.

I think if you base your opinion on what other people say, including me, then maybe you shouldn't comment? All of this is discussed first hand on the Wayland web site and/or mailing list.

Unfortunately since I've posted a bit late, I doubt many will read this...