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."
...year of Linux at last?
Palm trees and 8
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.
As long as there are slaughterhouses, there will be battlefields.
For including Wayland in Ubuntu:
http://brainstorm.ubuntu.com/idea/15205/
It is dangerous to be right when the government is wrong.
...year of Linux at last?
This sentence no verb and no desktop.
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.
Wayland-Yutani, "Building better X-servers"
-ubuntu others as you would have others ubuntu you.
They'll probably do the same thing they did with X.Org: Circumvent the entire thing.
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?
Javascript + Nintendo DSi = DSiCade
Instead of taking the initiative and starting the project yourself, like this guy did.
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...
Bow-ties are cool.
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.
Finally! A year of moderation! Ready for 2019?
He accidentally the whole verb and the whole desktop.
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.
Sam ty sig.
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.
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.
Javascript + Nintendo DSi = DSiCade
We're talking about X. You seem to have wandered onto some other topic. ;)
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.
I disagree. I think that a single distro gaining popularity will be instrumental for standardizing what is expected of Linux for introduction into a larger market...that is, to give hardware and software developers a system to work in that's more standardized.
It is pitch black. You are likely to be eaten by a grue.
Getting it into the Ubuntu repos probably wouldn't hurt, either. (Sad that a single distro can have that much influence)
Wow. The Economy must be bad! People are getting their Ubuntus repossessed!
You do understand, don't you, that the reason the nVidia drivers aren't in the Ubuntu (or Fedora) repos are that they're not OSS? Ubuntu will quite happily download and install them if needed, but they'll also make sure you know they're third-party and not supported by Ubuntu. For Fedora, you need to add a third-party repo (livna) after which installing the drivers and keeping them current is simplicity itself. I don't know about other distros, but I'd presume it's similar for all of them, with the probable exception of Gentoo.
Good, inexpensive web hosting
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.
I use X on 32 and 64 bit versions of both OpenBSD and Ubuntu Linux and can't recall it crashing on my anytime in the recent past. Certainly not "all the time" in my experience.
Trolling is a art,
I hear a lot of (I bet) young people clamoring for X to die, and that would somehow improve Linux or Unix.
X does not need and should not be allowed to die. Sadly X11 is probably one of the coolest pieces of misunderstood software on the planet. It is a bit dated and it does need a code cleanup/refactor, but because of proper design, that can happen without breaking the system.
To those who have *no* understanding of X, they should try this:
ssh -XC some_linux_machine
eyes
What happens is that the "display" is a network device. Windows terminal server and citrix, even today, can't easily separate application from display. X has had it for years. It isn't an afterthought requiring drivers to probe and figure out what got changed on the display surface and send a block over the network (like citrix and VNC), no the display is rendered over the network.
X11, IMHO, is one of those hidden jewels in Unix that don't quite get. They focus on trying to make it like Windows or be a gaming platform, but UNIX is a "productivity" platform.
Like I said, I'm all for refactoring, cleanup, cruft-removal, etc. to the codebase, but keep X11.
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.
We went through the same thing when switching to X.org from XFree86. When will nVidia support it? When will ATi support it? When will my driver be ported?
Why is X dealing directly with the drivers anyway? Why isn't there a thin graphics layer in Linux, like a framebuffer that supports acceleration? Write X to that. Then you can switch your X or use whatever GUI you want and you hardware still works. Freedom to choose, right? The mantra of Open Source?
I remember a bunch of very promising GUIs coming up in the early 2000s that really struggled without enough drivers. "The source is open, just port the thousands of drivers!" yeah sure.
boldly going forward, 'cause we can't find reverse
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
That's almost exactly how it already is right now. This whole thread is a bit strange to me since everyone's complaints about X are based mostly on their misunderstanding of how it actually works.