Slashdot Mirror
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."
Uh, what else? None of these have replaced the X11 standard.
True, but this isn't aiming to replace the X11 standard for all purposes, at least not for the moment. The article/interview seems to make it clear that the goal is to do lightweight sorts of things - login managers and screen savers first, remote desktop access later - that don't have necessarily complicated needs beyond being able to fire up quickly, not take up that much space, and hopefully look nice in the process.
This isn't the New Linux Desktop. (unless it is.)
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.
OS X *is* NeXT. So I'd say that "that stuff" went to good use.
Not sure what you're referring to. But BeOS was awesome. Especially when it came to multimedia.
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.
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.
I don't think that most of them were trying to.
Javascript + Nintendo DSi = DSiCade
This doesn't replace the X11 standard. It's just another implementation of it. I guess this means porting applications is unnecessary, except for maybe a relinking.
The chances that X11 gets replaced are pretty small but the replacement of X.Org seems a bit more plausible.
As long as there are slaughterhouses, there will be battlefields.
1. it's very primitive. If you've got a VM to try it on, then go for it.
2. As AC on another post correctly listed the projects like this that have come before it. So, before everyone starts beating-up on X11, they need to check out the ample supply of unpopular alternatives.
The framebuffer is rarely discussed as yet another alternative to X11.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
None of these have replaced the X11 standard.
X11 in 2008 is a lot different from X11 in 1998. Much of the X11 API is never used, and therefore you can get away with making a much simpler X-server which only supports the new calls. It won't run very old programs without some sort of compatibility box, but those are fairly rare.
Finally! A year of moderation! Ready for 2019?
Getting it into the Ubuntu repos probably wouldn't hurt, either. (Sad that a single distro can have that much influence)
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.
Though before you think this will replace the current X.Org Server, Kristian explains "at this point wayland is just a prototype/playground for some ideas I've been toying with."
Heh. What would be cool would be if someone thought of this use case. The protocols, API, and ABI need to keep going higher level to support remote desktop scenarios too. I'd like to see your case work by sending application data streams such as H.264 through the server to a remote system where they are decoded and physically composited onto the display. And the remote display should have the compositing and window management logic to allow "rootless" display as an option if the user wants it, rather than if the application and remote desktop software feel like providing it. And then detach the session and migrate the user to another system and do the same thing. It should not render to a bitmap and then send that via the remote desktop protocol.
All the really big players keep them in a separate repository. The "biggest" distro that I know that includes them normally would be Gentoo as you mentioned, and Sabayon, a Gentoo off-shoot.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
I don't understand why you were modded down, when you are technically correct: nVidia's driver stack simply doesn't use most of X.org's API/ABI. There are actually bits and pieces of X that we'd like to deprecate, but we can't because the nVidia blobs need them in order to do their thing.
~ C.
If he really wants Linux to compete with OS X in terms of interface, he should focus on the X Server first.
Why? What do you personally dislike about X in general (or X.org in particular)? I installed Ubuntu 8.10 on my work Dell and it correctly autoconfigured everything from my subpixel antialiasing on my LCD to my 7-button Microsoft trackball to my Model M keyboard, using the open source accelerated Radeon drivers for my ATI card. I have a nice, composited desktop with no tweaking necessary. What more should I be expecting from my graphics layer?
Dewey, what part of this looks like authorities should be involved?
You don't know what you're talking about. When not using network transparency, X.org uses unix domain sockets which are very fast. Given that you've got to do IPC somehow, and a well designed protocol will work just as well over TCP sockets as unix sockets, you basically get network transparency for free.
Give me Classic Slashdot or give me death!
Jon Smirl and David Reveman lobbied for a new xorg server built on OpenGL. It got little support from the community especially from Red Hat and Novell. Personally I think this was one of the greatest missed opportunities in the history of OSS. We could have had a modern xorg server replacement which rivaled Apple and Microsoft. Now we have the main xorg branch floundering from lack of interest and developers. Not to say there hasn't been progress made but no one can argue that xorg has the resources available to compete.
Ironically someone who argued against X on OpenGL now is working on his own xorg server replacement. Good luck to him and I hope he has better support.
The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
No, Vista removed the most complex bits of drivers from the kernel space. In essence, Vista kernel now controls modesetting, command submission, memory allocation and GPU scheduling. Also, some legacy graphics functions and some parts of USER subsystem remain in the kernel, but by now they are very well debugged and stable.
The rest (like compiling shaders and window compositing) is done in user-space.
X.org actually slowly moves to this model.
NT was a ground up rewrite. There's little OS/2 has in common with NT, even though the original intent was that NT be OS/2 version 3. Early in the project, Microsoft ditched the idea, and all that's left of OS/2 is a user-space subsystem that provides most of the OS/2 API with the glaring exception of Presentation Manager (the OS/2 GUI.)
Microsoft's decision to throw away OS/2 and stop working on it in favour of NT is why Microsoft and IBM split, and then ended up hating one another and acting like children.
You are not alone. This is not normal. None of this is normal.
Just like on OSX, you have a rootless X server that is a client (an application if you like) of the native windowing system and acts as a server for the X clients (applications) that need an X server in order to interface with the user. So it is both an application and a server.
1) NO ONE programs with xlib.
2) X doesn't "suffer" from being network transparent from the point of view of the user.
I don't even want to think about setting up some kludge like VNC to deal with a future Unix GUI subsystem that isn't network aware.
With X, I can just treat a network of machines like one big hive mind. Just make sure to set $DISPLAY.
A Pirate and a Puritan look the same on a balance sheet.
I used it last week, I needed to change some settings on my MythTV server and couldn't be bothered to walk to the shed (!) so ran SSH -X from my laptop. Yes, I could do that with VNC or similar but it's nowhere near as neat having to run a desktop in a window on a desktop. Remote tunneled X allows me to run programmes on a remote machine seamlessly on my own desktop and is a feature that is used by thousands of people - maybe a lot more - every day. And it really doesn't slow things down at all.
Kernel modesetting is a good thing, but there is no need to put the drivers into the kernel. KMS gets you lots of good things: BSoD (much better than the display freezing with no error message), flicker-free boot, and X could be moved away from needing to run as root.
As far as the drivers themselves, the best thing for them will be the move to the Gallium3D driver model, which will greatly reduce the amount and complexity of code needed to write a new driver. [1][2][3]
Keith Packard talks in his blog [4] about kernel mode drivers, but this seems to be KMS + memory management (GEM or TTM), not having, say, the entire Radeon driver in kernel. I guess it depends on how you define drivers. or maybe the difference between classic 2d drivers and DRM drivers (I have never figured out the details of that)?
>Today's X servers still support all kinds of usermode drivers, just so that 95% of configurations can thunk it all to the kernel.
All X drivers are usermode. There are graphics drivers that are in the kernel (fbdev), but these are unrelated to X.
Note: I am not a X dev or even a real programmer, but I follow X blogs, mailing lists, etc, and I try to learn as much as possible about X. If I am wrong about anything here, please correct me!
[1] http://www.tungstengraphics.com/wiki/index.php/Gallium3D
[2] http://akademy.kde.org/conference/presentation/9.php
[3] http://zrusin.blogspot.com/search/label/Gallium3D
[4] http://keithp.com/blogs/kernel-mode-drivers/
Climate Progress - Hell and High Water
Replyin' to my own comment, since it's drawing some attention...
A little background: I've been only dabbling in the free Unix game since I switched to Mac a few years back -- partly *because* of my frustrations with X11 -- so some of my impressions are out of date, There's no question the UI layers on top of X have improved by leaps and bounds since then. And I'm by no means an X developer.
Yes, I understand that X is intended to be a rendering engine, and that user interaction isn't its main job. Yet somehow, it seems to me that I *constantly* end up having to muck with userland X configuration scripts and reading cryptic X man pages in order to get my application running, if that application is anything more arcane than a web browser. If the goal is to make a black box labeled "No user serviceable parts inside", then it had better work without twiddling. And it doesn't.
Sounds like Xorg is making good progress, but I'm hoping for more. Borrow as much Xorg code as you can, but make the leap and blow a gigantic hole in backward compatibility, and focus on building a top-notch modern rendering system. Talk to the Gnome and KDE dudes to make sure you've got an API they're prepared to handle, and let xeyes and xclock and twm and fvwm slowly twist in the wind.
Every piece of software reaches a point where a ground-up re-engineering (which is not the same as a ground-up rewrite) is the best option, even if you lose backward compatibility. Apple, for instance, seems to do this about every 10 years. Not saying you should emulate them, but 20 years is just too damned long.
The demo apps that came with it worked pretty well. It was a lot smoother than X's compositing window managers at the time at any rate, but that's mostly because nvidia can't write a 2D driver worth shit and Y was software-rendered.
But like everyone else has said in these comments how is this attempt going to be any different to Y/DFB/GGI/etc?
X does not *have* to run the graphics ... just because Xorg/Xfree86 and just X before that (usually?) worked that way, that doesn't mean it's the only way it can be done. Counter-examples include X on OS X (yes, I know, it was mentioned), X on Windows, and even things like Xvnc, Xvfb and Xnest.
Just because YOUR X server also manages the graphics hardware, that doesn't mean that's an X thing -- it just means it's something else that YOUR X server does. Others may not.
FishWithAHammer was just not very clear.
Context for those who need it
How much memory do you have? I've mostly seen X crash while something is hogging all the memory and paging is slowing everything down. It's not common even with limited memory, but it does happen.
Checkout MicroXwin (http://www.microxwin.com).
Like Windows NT X11 graphics is done in the kernel.
There is no IPC and no networking overhead. Company claims that the solution is small, fast and compatible with existing toolkits.
``Why is X dealing directly with the drivers anyway? Why isn't there a thin graphics layer in Linux''
Don't forget that Linux is not the only game in town. X.org suppors Linux, but it also supports FreeBSD, NetBSD, OpenBSD, Solaris, UnixWare, LynxOS and HURD. I think there are actually more, but those are the ones listed in the manpage.
If we do as you propose and make the operating system kernel supply the drivers, drivers would have to be written for all those 7 kernels, instead of just once for X.org. What we have now is exactly how I like things to be: a common driver API across operating systems, so that drivers need be written only once.
Please correct me if I got my facts wrong.
And why modded _you_ insightful? The X11 protocol most definitely does NOT "blit the entire damn window over the network". That's how things like VNC and MS' Remote Desktop work (although with a lot of compression to make it workable).
But it is true that the protocol was made to work over relatively fast local network connections so not much thought was put into limiting the amount of traffic.
But if you want X over a slow connection you could try NX (http://en.wikipedia.org/wiki/NX_technology).
I have to say, running on 512K ram and it seems to be fine. The only time I've had a real problem with X is when I start fiddling with Nvidia drivers and 3D acceleration. I've always put that down to the drivers not playing nicely though.
Silly rabbit
And client side (font) rendering is good exactly _how_?
It means innovation can happen in the client libraries and not have to wait for all the servers to catch up. It can lead to fewer roundtrips between clients and servers.
You should never enshrine complex things in protocol specifications; protocols change way too slowly. Font rendering used to be a simple thing, but the demands of modern applications force it to be complex, and the X11 protocol simply can't keep up. Nor should it.
I don't have client-side rendering problems with ssh transparency. If anything, it helps that you don't have to install all the fonts an application needs on all the X-servers it might end up running on.
Finally! A year of moderation! Ready for 2019?
and with -C as well, I speed up at low latency links. Further FreeNX/NX do the trick for even lower latency links, also under a ssh tunnel.
Sorry, you are totally wrong, that's not how X11 works at all.
The client queues up a set of drawing commands (not bitmaps), at some point the queue gets flushed, and for a local display there's a context switch and the server updates the screen. This is exactly how Windows and OS X work as well. The only difference is that the X11 protocol was carefully designed to be asynchronous, so that when you run over a network connection rather than locally, you don't get killed by latency on round trips.
Browser apps are nice in many ways, but that's a separate issue from the display architecture.
Bad things about X11: primitive drawing model, too much hardware management (this is an X.org problem rather than an X11 one, really), a lot of legacy. Most of the things that are actually bad are being or have been fixed.
Care to clarify what you mean?
Something has to run the graphics. In general, in Unix, this would be a process or the kernel. Assuming you don't think it's a good responsibility for the kernel (it really isn't, other than the memory protection issues that come up with memory-accessing and memory-mapped hardware) then it has to be a process.
Things share the screen in graphical environments. One piece co-ordinates that sharing and manages the desktop. That process is therefore providing a service and is always a server, whether it's X or the MacOS system.
So, userspace server it is, then.
"Who's to say anything else would be more stable than the above cut-down X server?"
I think the point of Wayland is that it's actually not an X server at all (despite misleading article title) but could be used as an X server replacement for Linux; applications would have to be written or ported to it as it wouldn't be running the X protocol (however, a port of the X server could allow X apps to run in the same way as running an X server on Windows or OSX allows you to use X apps on those platforms).
All in all, this seems like A Good Thing(tm)
The revolution will not be televised... but it will have a page on Wikipedia
All folks who claim that X's problems lay in it's *ability* to use clients over a network are 17 years late. I.e., they have no clue at all. There are problems with X, but they are elsewhere.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
What X11 does is blit the entire damn window over the network.
No, not unless you're using the crappy toolkit from hell or trying to do compositing without hardware support. Usually X11 works by sending higher-level instructions like "draw a line from A to B".
HTML+AJAX is doing now what X11 should've been doing 20 years ago.
Solving a different problem through the addition of horrible hacks and a security arms race? O RLY?
I don't know enough about Citrix or WTS to know how thin their client is, but I'm betting it's a lot thinner than X11.
It's quite possible to slim things down by making more assumptions, resulting in less portable applications. I'd not rush to declare that this makes one better than the other though; X11's stood the passage of time remarkably well compared with other things of the same vintage (let alone the products you mention, which came much later and could hence incorporate a lot of experience).
Those who don't understand exactly what X11 does are doomed to rubbish it and, by doing so, look foolish.
"Little does he know, but there is no 'I' in 'Idiot'!"
The problem with Windows is not that window drawing is done on by the client. The problem is that no event can be processed without the wndproc for that window looking at it first. So if the application isn't processing events, the window can't move. X does it a bit differently in that you only receive events you request. Most X apps probably aren't interested in processing the move event, but if it does process it, I'll bet you'll get a similar effect with X.
They both have I/O managers
You sure VMS isn't a rip-off of Linux?
They both have demand-paged VM, like most modern operating systems
They both have executive layers.
Wow, so Intel was in on it too?
They both have scheduling priorities, like most modern operating systems - they both happen to have 32 levels.
Oh come on!
Things you missed: they both have kernels, they both have file systems, they both support filesystems that have a dot separating the name from the extension, they both use ".EXE" as an executable file type, they both have command lines, they both...
I'll say it again, slowly: VMS is a monolithic operating system. Windows NT uses a microkernel. Like all operating systems, you can find features of one that's in the other. But NT resembles VMS about as much as it resembles Unix. Most of the key components do not resemble one another in any way, the file system, shell (and role of the shell), API, and general architecture are so completely different I'm amazed people continue to bang on with this garbage. You can even SEE WHERE THE SODDING THINGS CAME FROM. Win32 is the Windows API, upgraded to a 32 bit version. Have you seen it? It predates Cutler joining Microsoft by about seven years. It was developed by people who'd seen more Unix than they'd seen VMS. The file system? An advancement on DOS, complete with 8.3 filenames and basic "stream of characters" type files (no indexed record-based file system for you.) The shell? Again, based on DOS, itself based originally on CP/M but with minor modifications, and the shell has little or no use by the operating system itself, unlike VMS where its central to the operating system's operation.
There's no comparison. They're not the same operating system. People come up with ways they're similar, but ignore the fact that you can compare any two operating systems and find similarities. AmigaOS also has an executive, is a microkernel, and has 32 levels of process priority. Is it based on VMS, or was Windows NT based on AmigaOS?
You are not alone. This is not normal. None of this is normal.