How Important Is The Wayland Display Server?

[lee_b]

Let's clear this up

Guys.. forget wayland. The thing you're all looking for, which has been mentioned a few times, but mostly missed, is this:

Xorg State Tracker: The Last Xorg Driver (previously known as xorg-video-modesetting)

With it, Xorg is just a library of things like low-level window management and input device management. Even the input management is being simplified, with Linux's recent generic event-driven input device support.

The Xorg State Tracker will swap video modes using kernel calls to GEM, so it doesn't know about your graphics card, and will work very smoothly, without crashing.

OpenGL, Xv, VDPAU, and all other rendering will/can be accelerated using Gallium3D, for optimal performance.

The Gallium3D drivers for your card will be much smaller and simpler than the old xorg-video drivers, and the OpenGL drivers, so graphics card vendors or Open Source developers will be able to support Linux much more easily. Moreover, a Gallium3D driver will be very portable to FreeBSD and Haiku and other Operating Systems (if not directly compatible), so there's a bigger market to encourage them to write those drivers, and a bigger pool of open source developers to work on free versions.

For those of you who want a simpler, cleaner X, this Xorg State Tracker is it. And it's coming.

[89c51]

@Michael

I think that an interview with Kristian would be a good idea ie promotion for the project (or clear his views) and for us to listen what he wants to do with wayland and whats the future of it etc

pleaseee

[movieman]

Nonsense. Most applications make heavy use of toolkits for almost everything.

And those toolkits render to X; yes, every single toolkit can be rewritten to write to some new 'X alternative', but that's not going to happen any time soon, particularly as most of the people maintaining and developing those toolkits probably have better things to do with adding high-level functionality than add yet another low-level interface.

X.org is not multi-process.

Windows, for example, has an application process and when the application wants to render it calls the operating system where it waits on a semaphore until every other application has stopped trying to access the hardware, then it can actually do its own rendering. X has application processes which pack up data and send it to the X rendering process, which can work independently. It also has the window manager as a separate process which can do its thing independently.

At some point access to the hardware has to be serialised, but with the buffering due to the inter-process interface in X, there's much more opportunity for overlapping processing than every application having to wait when one application is accessing the hardware.

Thankfully, Kristian understands X very well.

I wasn't specifically talking about him, but the numerous 'X is awful, we must replace it with something else' messages here from people who don't even seem to understand what X does or how it works.

[elanthis]

Aside from the fact that nothing will run on this 'X alternative' unless it supports the X protocol... in which case it's X.

Nonsense. Most applications make heavy use of toolkits for almost everything. Some of the current toolkits expose X internals to apps (e.g. GTK+), but that's changing with the next major releases.

If your app uses only the toolkit APIs for events and rendering then your app will be able to run on any display server the toolkit supports. If the toolkit API is well designed you won't even need to recompile or relink your application, but just swap in a different shared library... or use the same one if the toolkit supports multiple backends in the same binary (relatively unlikely, but totally feasible).

I do agree that there's a place for a simple, lightweight graphics interface which stays as close to the hardware as possible

Like the kdrive X server.

Another issue to consider is that as CPUs gain more and more cores, any future monolithic graphics interface is going to become increasingly inefficient compared to a multi-process implementation like X.

X.org is not multi-process. I think input was split off into another thread (or that was experimented with, at least), but that's it. The only thing Wayland pulls into the core server is the WM/compositor (which is dangerous for the reasons I outlined previously, and not because of a performance issue -- it's actually beneficial for performance because X and the compositor no longer have latency problems from the excessive amounts of communication they need to do for simple things like translating input coordinates for composited windows).

You really don't want to have every application waiting on a single-threaded graphics interface if you can just package up your commands and send them off to another process which handles them for you.

Which is how both X and Wayland work. X still has internal rendering facilities applications can route through, but the goal even for X is to just have apps render through the DRM using Gallium.

Seems to me that just as people who don't understand unix keep trying to reimplement it... badly, people who don't understand X keep trying to reimplement it badly too.

Thankfully, Kristian understands X very well. Wayland has a number of advantages beyond just being a replacement for X. One of the ideas for Wayland is to convert X into just a thin protocol wrapper over Wayland, use for compatibility and networkings, while letting Wayland do all the important work. If nothing else is solves some interesting desktop multiplexing issues without needing to do yet more major surgery on X's internals.

In the long run, though, I see Wayland vs X.org much as I saw AIGLX vs Xglx (which played out exactly how I thought it would, despite the seemingly overwhelming popularity of Xglx at the time). Wayland is a window into what the display server can become. X.org, despite having a somewhat slow and plodding pace, will get to the same point Wayland is already at but be better for having taken its time and not throwing out features for flash and sparkles. X will gain all the capabilities of Wayland, it will maintain network transparency, it will maintain compatibility with old binaries, and it will trim out the cruft only when the cruft is no longer useful.

X will also retain truly useful capabilities that Wayland will never have, like full network-transparent GL acceleration. Aside from just being cool, it is actually used heavily in a number of organizations. The Linux desktop space is far bigger than just the computer sitting on your desktop at home. Given that being able to accelerate GL over the network has zero impact on the efficiency of accelerating GL locally (local GL doesn't use the wire protocol at all, beyond display configuration -- all actual rendering is done with the DRI), there's no reason to believe that throwing out the network feature will benefit anybody at all.

Remember, people -- evolution before revolution. Throwing everything out and starting over when you can just improve and trim an existing codebase is the kind of the decision that would get your ass fired in a real programming job for wasting a huge amount of time and money... and it's the kind of decision that should get your ass booted off an Open Source project for wasting everyone else's time and money, too.

Dedication to "purified technology" over dedication to "things that are actually useful and helpful to people using the technology" doesn't make you a great engineer; it makes you a pain in the ass that actually retards the growth of everyone else's technology. If you force GTK+ and Qt and XUL and so on to all spent a few months writing Wayland support into the toolkit, testing it, porting feature, fixing APIs, and forcing application authors to fix up any X dependencies themselves, then you've just forced a massive number of people to perform a massive amount of work just to get a purified display server... that same time and effort could have gone into support Gallium directly in the toolkits, updating applications to use new features found in X and Wayland both, adding new features that actually matter to users, and so on.

The good engineer is the one who facilitates that user-oriented growth in the entire desktop ecosystem. The bad engineer is the one who stops all the growth for 6-12 months to force everybody to use the new "better" technology that doesn't actually do anything interesting for the user that the old technology couldn't do.

[markg85]

Aside from the fact that nothing will run on this 'X alternative' unless it supports the X protocol... in which case it's X. Sure, one day perhaps every X program will have been rebuilt to run on the 'X alternative', but that's a long way off.

Again, your comments have largely been addressed in this thread by pointing out all the work which is going on to separate drivers from X so that they can be used by other graphics interfaces; X then becomes just another interface to those drivers.

I do agree that there's a place for a simple, lightweight graphics interface which stays as close to the hardware as possible: when I was developing embedded media players a few years back we threw away the whole of X and wrote directly to the framebuffer with our own hardware. Maybe this will be that interface, but while that's useful -- in fact, probably required -- for such special cases, it's not very useful for general applications.

Another issue to consider is that as CPUs gain more and more cores, any future monolithic graphics interface is going to become increasingly inefficient compared to a multi-process implementation like X. You really don't want to have every application waiting on a single-threaded graphics interface if you can just package up your commands and send them off to another process which handles them for you.

Seems to me that just as people who don't understand unix keep trying to reimplement it... badly, people who don't understand X keep trying to reimplement it badly too.

There is a good alternative working today: DirectFB (website seems to be down a.t.m.) however it requires drivers in the kernel thus only intel is "usable" (if you can get it working at all) with hardware acceleration. And till this moment it's used mostly on embedded devices and seems to be relatively unknown on the linux desktop. If i have the time i still plan on trying to continue my work on a desktop environment build on top of directfb.

Best thing for DirectFB imho would be to somehow support the X video drivers.

[movieman]

IF there is a X alternative that can either use the X drivers or just has good video drivers equal to X then X is dead.

Aside from the fact that nothing will run on this 'X alternative' unless it supports the X protocol... in which case it's X. Sure, one day perhaps every X program will have been rebuilt to run on the 'X alternative', but that's a long way off.

Again, your comments have largely been addressed in this thread by pointing out all the work which is going on to separate drivers from X so that they can be used by other graphics interfaces; X then becomes just another interface to those drivers.

I do agree that there's a place for a simple, lightweight graphics interface which stays as close to the hardware as possible: when I was developing embedded media players a few years back we threw away the whole of X and wrote directly to the framebuffer with our own hardware. Maybe this will be that interface, but while that's useful -- in fact, probably required -- for such special cases, it's not very useful for general applications.

Another issue to consider is that as CPUs gain more and more cores, any future monolithic graphics interface is going to become increasingly inefficient compared to a multi-process implementation like X. You really don't want to have every application waiting on a single-threaded graphics interface if you can just package up your commands and send them off to another process which handles them for you.

Seems to me that just as people who don't understand unix keep trying to reimplement it... badly, people who don't understand X keep trying to reimplement it badly too.

[markg85]

How important though do you think Wayland is? Will it succeed? What do you think of the X.Org stack? What do you think will happen to it in the coming years? Share with us your answers in the forums.

for X.Org. It will die. The sad state today is just that X is the default in nearly every linux distribution and has the graphics drives. Those 2 facts will give X a long time before people finally realize that X isn't the best way to go. Wayland might be better but don't count DirectFB out yet! They are under development and releasing new versions from time to time.

I see only one future fox X other then dying and that is a (near) total rewrite of it. anything else is probably just not going to save it.

O and the massive delays in X releases the last few years is (to me) a clear sign of a dying project. however currently it's to important to die so company's will probably keep it developed till there is a better alternative.

Mark my words. IF there is a X alternative that can either use the X drivers or just has good video drivers equal to X then X is dead.

[nanonyme]

Even first ADSL used to be around 30 ms before Elisa did upgrade the routing equipment. But it is amazing how much cable latencies are improved from that time (I'm using cable connection now). They used to be nearly as bad as with modems. That did mean 100-200ms.

Yeah but there still seems to be some limitation to latencies brought by the ADSL technology itself that is not existent in Ethernet Internet connections. I'm hoping we'll eventually move to some technology that enables latencies like the ones we have here in TKK student village campus (really, Finland is mostly a LAN to us) some day that'll be cheap enough for average consumers.

[suokko]

Oh, right. You get to forget ADSL actually suffers of latencies when you use Ethernet for Internet for a while. Usual latencies for me inside country are about 1.5ms.
But yeah, modem latencies can easily rise up to a hundred milliseconds, ISDN was iirc around 50 or so. 15ms sounds pretty normal for an ADSL.

Even first ADSL used to be around 30 ms before Elisa did upgrade the routing equipment. But it is amazing how much cable latencies are improved from that time (I'm using cable connection now). They used to be nearly as bad as with modems. That did mean 100-200ms.

[nanonyme]

How horrible latency you have? My 1M connection can even run basic remote applications because my ping inside country is worst case 15ms in evening time. Best case latencies are about 8ms when traffic is not maxed in my ISP network.

Oh, right. You get to forget ADSL actually suffers of latencies when you use Ethernet for Internet for a while. Usual latencies for me inside country are about 1.5ms.
But yeah, modem latencies can easily rise up to a hundred milliseconds, ISDN was iirc around 50 or so. 15ms sounds pretty normal for an ADSL.