Wayland, a New X Server For Linux

An anonymous reader writes "Phoronix has a new article out on Wayland: A New X Server For Linux. One of Red Hat's engineers has started writing a new X11 server around today's needs and to eliminate the cruft that has been in this critical piece of free software for more than a decade. This new server is called Wayland and it is designed with newer hardware features like kernel mode-setting and a kernel memory manager for graphics. Wayland is also dramatically simpler to target for in development. A compositing manager is embedded into the Wayland server and ensures 'every frame is perfect' according to the project's leader."

Does this...

...spell the death-knell of X-based graphics drivers? Does this mean that such drivers will finally be folded into pure kernel modules with no fancy wrappers required? Does that also mean that we can eliminate X as a dependency for playing video games, and using Linux in multimedia or kiosk environments?

Re:Does this...

...year of Linux at last?

Re:Does this...

...year of Linux at last?

This sentence no verb and no desktop.

Re:Does this...

He accidentally the whole verb and the whole desktop.

Re:Does this...

Now only to convince nVidia to release their drivers for this new X. As long as these things don't happen, this probably won't take off.
Man, we really need OSS drivers.

Re:Does this...

They'll probably do the same thing they did with X.Org: Circumvent the entire thing [blogspot.com].

Re:Does this...

But if you're going to "get rid of the cruft", doesn't that suggest that you'd want to move to an architecture that depends on the kernel's graphics subsystem rather than maintaining a zoo of obsolete usermode drivers?

Hardware is the purview of the kernel. Or at least the Hardware Abstraction Layer. (Depending upon your OS's architecture.) Today's X servers still support all kinds of usermode drivers, just so that 95% of configurations can thunk it all to the kernel. Thus there doesn't seem to be much point in providing the graphics drivers in the X server. Better to let the kernel do its job while the X server does its job of drawing the GUI through interpreting a series of abstract commands.

As a bonus, the graphical system becomes available to a variety of programs that desire low-level access to the graphics card rather than running an X server.

Perhaps I'm being naive, but why wouldn't a clean separation between the graphics system and the kernel drivers be an advantageous goal?

Re:Does this...

Microsoft moved the ENTIRE graphical subsystem to the kernel. Which made things faster, but did make them less stable and less secure. (Sun also had an option to take this route in Solaris.) This would be like taking the entire X server and cramming it down into the kernel.

I'm not suggesting anything quite so extreme. Rather, I'm talking about leaving device control in the hands of the device manager (i.e. the kernel or the HAL) and having the X server access the device through a standard driver interface. Much like audio, mouse, keyboard, networking, and storage are all handled by the kernel.

FWIW, Microsoft left the graphics in the kernel. They did add some extra checks to stabilize it, but we're all living with those kernel graphics today.

Its good to see Red Hat developers doing this

While I'm a firm believer in "If it ain't broke, don't fix it", I think it is good to see Red Hat developers (or any developers) looking to future needs and being allowed to devote development time towards those needs.

Xorg isn't broken for most users right now, but planning and creating alternatives is a good idea.

What's wrong with X...

Xorg isn't broken for most users right now, but planning and creating alternatives is a good idea.

In a sense I think it really is... Admittedly, not necessarily in a way that everybody would notice, as you said - but still...

What X is good at, basically, is putting simple UIs over a network. For instance, I can run XEmacs remotely over the internet, and performance is decent.

Presently, this feature of X is being under-utilized. We're using a network-transparent protocol for the display server, but most people aren't running apps from remote hosts, and applications aren't being written with this in mind.

Basically, for all the overhead associated with something like X to be worthwhile then one of a few possible conditions must be satisfied. Either applications must be designed such that they work efficiently over the network with the present limitations in the display protocol, or the display protocol must be enhanced or altered such that today's applications can run reasonably well over a network link.

Running X apps over an internet link versus a LAN is an extreme case, admittedly - but nevertheless, an old Athena app can do it, while the simplest of GTK or QT apps can have a real problem with it...

Re:Its good to see Red Hat developers doing this

While I'm a firm believer in "If it ain't broke, don't fix it"

We're talking about X. You seem to have wandered onto some other topic. ;)

There is alreeady a brainstorm...

For including Wayland in Ubuntu:
http://brainstorm.ubuntu.com/idea/15205/ [ubuntu.com]

HELL yes.

eliminate the cruft

ABOUT F'ING TIME.

X has been a case study in How Not to Write Software for twenty years now. Once upon a time, it was a pretty cool experimental software project. But for twenty years now, there have been exactly two kinds of X development:

A) Throw a layer on top of it to make it useable for normal people

B) Throw another driver underneath it to make it just barely work on your particular hardware.

Project A is fine until someone has to get beyond your little layer, in which case it's .xinitrc hell. Project B is just treading water, postponing the day that we all realize this indispensable software tool is a gigantic house of cards headed for collapse.

Probably some XFree86 dudes are reading this. Let me just tell you I appreciate your diligence in the nightmare of a job you've set yourself to, but the time has come. Take off and nuke the site from orbit. It's the only way to be sure.

Re:HELL yes.

Project A is fine until someone has to get beyond your little layer, in which case it's .xinitrc hell.

What in the world does the X11 rendering engine have to do with "useable for normal people" or the "xinitrc"?

X11, and by extension, the X server, is a layer whose job is to put stuff on screen. That means dealing with the wibbly bits (mice, keyboards, displays, video cards, tablets, pedals, etc.) that cause the stuff on screen to be displayed or interact with the stuff on screen.

But for twenty years now, there have been exactly two kinds of X development:

Furthermore, it's not like people haven't been modifying how the bits in between your "Project A" and "Project B" work, either. See xrandr 1.2 and 1.3, for example, as well as the countless other projects working on this very part of X11.

That's not to say there aren't problems with X11 and the various implementations of the X server, but it'd help to at least have studied what's actually going on before attacking the work of those who are actually doing the work.

Wayland-Yutani

Wayland-Yutani, "Building better X-servers"

Y windows; drivers

There's another project called Y Windows [y-windows.org], which also aims to replace X with something that has less historical cruft.

The real question in my mind is whether this kind of thing does anything to address the big problems users are really encountering. Of course, not every open source project has to make large numbers of users happier. But the author of Y Windows says, for example, "I've got tired with the state of desktop GNU/Linux. Most of the problems that I see with it can be traced back to the underlying window system, X. So I decided to write its successor... "

For me as an end-user, the big issues are simply hassles with xorg not correctly recognizing LCD screens, so that it sets them to an inappropriate resolution, or the image appears offset. I have close to zero interest in gaming, so personally I just use the onboard video of my mobo, with only 2-d driver features, but the impression I get from people who do care about gaming (or fancy WMs) is that the big issue is drivers, not the internal structure of X.

As far as programming, the structure of X also seems like kind of a non-issue. Sure, X's APIs are heinously ugly, but almost nobody uses them directly.

The advantages listed by the article are things like a more manageable code base, a smaller memory footprint, and elimination of rendering artifacts. To me, none of those seem like major issues that I was all that worried about.

Re:Y windows; drivers

I remember when Y windows was slashdotted in Feb 2004. It sounded pretty interesting. Unfortunately, it also looks like there hasn't been a single news item on their web site since Feb 2004, and their "community wiki" link points to a domain-squatter-ad-site. Also, the downloads match the version announced in 2004.

It's dead, Jim.

Article misunderstands concept?

The article describes this as a "new X server". However it quotes the author of said program pretty much implying this is some kind of a new, non-X video interface. He talks about "porting" GTK+ from X, and about writing native applications for it and a "new, rootless X server" in order to be able to run X apps. All things that would not be necessary if this were an X server.

In other words, this is not an X server.

Canonical

Shuttleworth said he is going to pay devs to work on major upstream projects. He should focus on this. For one, it would affect both KDE and Gnome users, and it would solve a major problem with Linux. If he really wants Linux to compete with OS X in terms of interface, he should focus on the X Server first.

That being said, I hope Novell chips in some dev support, and that the KDE, Gnome, QT and GTK+ devs all chime on what they'd like to see changed.

Re:Been done (and failed) like a million times?

Xorg/XCB anyone?

If I understand the article correctly, this is a new X server, not a new API or protocol. Programs would still compile against XLib and still access the server through TCP/IP or unix sockets. The only difference is that the rendering engine that interprets those commands has been swapped out.

Then there is that stuff from NeXT which is similar to OS X.

OS X *is* NeXT. So I'd say that "that stuff" went to good use.

Then there is that BeOS-like server.

Not sure what you're referring to. But BeOS was awesome. Especially when it came to multimedia.

Framebuffer.

LFB is a pretty standard module in Linux these days. It's why Linux can boot with fancy graphical screens rather than staring at boring off-white text.

I think there was some sort of OpenGL server a number of years ago.

OpenGL is a standard part of modern X servers. Are you perhaps thinking of Project Looking Glass? That was an attempt at creating a new window manager rather than a new API. It's still under development, but it's coming along at Enlightenment speeds. Its development should not be impacted by a new X server.

Uh, what else? None of these have replaced the X11 standard.

I don't think that most of them were trying to.

Re:Been done (and failed) like a million times?

Port GTK/QT to this server's API ? If this server doesn't support a version of the X11 standard, then it's not an X server. Since it is being called an X server, no recompilation should be necessary, unless you're using X extensions that are not supported.

Re:Thank you!

Thank you sweet Jesus! Finally somebody is doing something that should have been done looooong time ago!

People have been doing bits and pieces of it for a long time. Client-side font handling, client-side rendering in general, kernel mode setting... Without those things, this project would be a lot larger.

This is quite typical of free software by the way: A lot of things are quietly replaced and enhanced without anyone noticing, and suddenly someone uses all the changed bits to create something radically new.

Re:Thank you!

Instead of taking the initiative and starting the project yourself, like this guy did.

Re:Thank you!

X is an application. *And* a server. On OS X as well. And under *nix, and even under Windows (when you add an X server to it.)

X's architecture works pretty well for what it was written to do. It was written in a time when lots of people used wimpy X terminals and did their work on a shared beefy central server.

VNC might be more of the architecture you're referring to?

Re:Notes for the Uninformed

It's rarely discussed because it's extremely slow. Even on low resolutions it takes an absurd amount of CPU power and latency. On high resolutions it's like a slide show with an awkward guest speaker. There's a reason we have hardware acceleration even for 2D.