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

what about xorg?

[sayfawa]

I did, at least, skim the article, and I still don't know. Didn't X11 just (as in last few years) get replaced with x.org? This is another replacement already? Ok, before posting, I google and see this:

What's different now is that a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries (cairo, pixman, freetype, fontconfig, pango etc) and there is very little left that has to happen in a central server process. ... [An X server has] a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. ... This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!) Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extension such as XRandR, XRender and COMPOSITE ... With Wayland we can move the X server and all its legacy technology to an optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if [we] don't plan for it.

which bored me to tears, so I'm no longer interested, but for those who are....

Re:what about xorg?

[Anonymous Coward]

[An X server has] a tremendous amount of functionality

X servers were working fine on resource-constrained Unix systems 20 years ago.

The idea that they're somehow too bloated compared to a modern UI subsystem is complete and utter bullshit.

It just makes me annoyed how everything becomes layer upon layer of yet more inefficient crap, yet we're supposed to worry about comparably simple "legacy protocols" possibly still having some features that could be gradually deprecated.

Re:what about xorg?

[smash]

Requirements for a display server were different 20 years ago. They weren't pushing around true colour bitmaps over the wan, video, openGL, etc. They were (realstically) rendering a few xterms, simple static bitmaps and not a hell of a lot else.

Re:what about xorg?

[Anonymous Coward]

I didn't see a whole lot of new hardware being added, but the code bloat was HUGE. like 3-5x the old sizes and still growing. X 3.3.3 was like sub 10 megs of archives, and it's now up to like 100(!)

OH MY GOD, NOT, LIKE, 100 MEGS, WHAT WILL WE DO?

Why are graphics awesome on Android?

[Andy Prough]

I've used various Linux distros for 13+ years, and have always been disappointed in the horrible desktop graphics. Compared to a Windows machine, a comparable Linux rig is normally a miserable graphics experience. I was shocked the first time I got my hands on a Xoom tablet - the graphics are by FAR one of the best features of the Android platform. I can't for the life of me understand how there can be such an extreme difference between graphics in desktop linux distros compared to the gorgeous and snappy graphics under Android. And I'm not even running garbage graphic cards - one of my machines has a very modern nVidia card that plays all the latest games under Windows, but still handles poorly on Linux. From a technical perspective, I can't understand how there could be such an absurd difference, other than that the Android kernel is a fork, and clearly the Android kernel developers are far more concerned about creating a pleasant and useful graphical experience?

Re:Why are graphics awesome on Android?

[Andy Prough]

I agree that the artwork is much better, but the responsiveness under Android is also clearly better, fonts are much nicer, videos and games play smoothly and flawlessly. Hell - my Android phone puts my Linux workstation with its $200 nVidia graphics card to shame.

Re:Why are graphics awesome on Android?

[Andy Prough]

I'm just talking about my personal experience. I often have dual-booted on the same system over the years, and right now I have two hard drives on my workstation - one that boots into Linux, one that boots into Windows. The difference in graphics rendering between Linux and Windows on the same equipment has always been clear - Windows has always handled graphics-intensive work much more smoothly. So why are graphics under Android so shockingly vivid and smooth?

I continue to run Linux because it can run circles around Windows for similar processor-intensive work - for example, I do a lot of OCR of scanned documents. On a large batch, I can get the OCR done in half the time under Linux compared with Windows.

Re:Why are graphics awesome on Android?

[ADRA]

Google invested a lot of money to get their Application client stacks to work very well with a sane OpenGL implementation, and OEM's shipping Android make sure that there are sane OpenGL implementations on Linux. The later cannot be said for any of the desktop players that have dropped the ball due to lack of interest for well over a decade.

Android proves that graphics on Linux can be quite successful functional, but it also proves at how little interest existing industry heavy weights have at supporting Linux in general. The question now looms, can AMD, Nvidia, Intel, and co continually give half hearted attempts at supporting Linux when their markets are now in more danger than they ever have before? Can they continually look a blind eye to one of the fastest growing consumer electronics segments in a long while? Time will tell, and the drivers (and standards bodies) will be the tell tale sign that they can truely embrase a world outside Windows PC's.

Increased performance?

[Smartcowboy]

Imagine recreating xlib so it doesn't communicate with an X server but directly draws things on the local screen, maybe in a multithreaded fashion. In such a scenario, the ability to share a display between many programs would be lost or alternatively a badly behaviored program could disrupt the other's windows. What kind of increased performance would be obtained (if any) by replacing IPC, as used in X11 (and in wayland too?) for drawing and use in process fonctions instead?

How long?

[whoever57]

but how much longer will it take to replace X11 on the Linux desktop? Quite a while seems likely."

Try never. Yes, I know that it should be possible to write a Wayland client that provides X11 server capability, but in that case, it is the Wayland client that is replacing X11, not Wayland.

Seriously, though, the Wayland effort appears to be throwing out every advantage the X11 display had over the Windows display for a replacement that will probably never be quite as good as a Windows. I just hope that developers of programs which currently support X11 continue to support X11, or my life will get much more difficult. In fact, for much of what I do, without X11 support (and only Wayland display supported), I would probably be better off with a Windows desktop instead of a Linux desktop.

Re:Good enough for Ubuntu

[socceroos]

Yep, the issue with constantly pushing forwards and looking for the next new thing means that you can periodically make a bad choice. Shuttleworth, while some of his descisions haven't been the best, has been instrumental in pushing the Linux desktop to where it is today. Linux has never enjoyed so many desktop users. That brings good and bad, but its still an overall positive.

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

[tibit]

It goes the other way: unless you design for network transparency from day one, you're not going to get it and have it perform well. There's no way to decently get network transparency as a layer on top of the window system. VNC and RDP are horrible kludges and perform like crap.

Re:Application and Screen on Different Machines

[complete loony]

Ok, so X11 sucks for local display, and it's not very good for remote display either.

I believe the plan going forward for local rendering with Wayland, is for the toolkit to render directly. I imagine that each toolkit might end up writing their own network transport for remote access, to give a better experience than just falling back to X11.

So what I think we need, is for the core team for each major toolkit to sit in a room and try to design an extensible network transport that they can all agree to use. With a core set of features, and perhaps some toolkit specific extensions. Perhaps ending up with a process similar to the way HTML has evolved over time.

Re:Hopefully another 25 years or more

[Anonymous Coward]

Or, we could just keep X. Much better.

Re:Hopefully another 25 years or more

[Anonymous Coward]

Unfortunately, this is not what people are objecting to. The problem is not that you cannot map X11 on-top of Wayland windows and run remote applications displaying on Wayland, the problem is that you cannot transparently display Wayland-windows on another machine.

On OS X and on Windows, it is not possible to display the native apps on a remote machine using X11.

The lack of network transparency will lead to every developer needing to ship two different applications, one linked to Wayland and the other to X11, then everyone need to download the correct app and install the one depending on their machine, i.e. on the machine that will be accessed remotely, install the X11 version on others install the Wayland version. Sure, we all know that you usually use GTK/Qt for applications, and while some of the issues could be solved by the GTK and Qt developers by cleaver dynamic linking to the display manager, often this works so-so and some apps will not be compatible with this, so you still need to run double testing for all your applications.

They should have started with defining the Wayland system in a way that was network-transparent, they could even have updated the protocols and made it more suitable for modern applications (i.e instead of sending delta-bitmaps, send the scenegraph updates for the window instead).