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
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?
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."
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.
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!
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.
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
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
``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.
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?
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]