Dual X Servers Running Side-By-Side With Wayland

[bridgman]

I'm just guessing, but I don't think krh wrote an X server replacement here; this would probably be X in its current form with drivers that use Wayland for drawing rather than hitting hardware directly.

[super7]

I'm no expert, but I would guess he can make a lot of progress since there is nothing stopping him from using existing Xserver and X.org code. It's not like he's starting completely from scratch...we all have the privilege to watch open source's benefits in action. I hope he continues making progress.

[airlied]

I'm just guessing, but I don't think krh wrote an X server replacement here; this would probably be X in its current form with drivers that use Wayland for drawing rather than hitting hardware directly.

oh it uses the hw alright, it just redirectks kms front buffers to wayland.

all this stuff needs kms.

Dave

[hoegsberg]

I have a FAQ page over in the Google group for the project that answers many of the questions here:

http://groups.google.com/group/wayla...keds-questions

cheers,
Kristian

[Vadi]

Thanks for the faq

[NeoBrain]

Hey, just wondering wether running two x servers under wayland could finally solve the "no minimizing in Linux" problem: Imagine the primary X server running under Wayland. The user starts some game, which gets hosted on a second x server, but wayland just draws the content of the second x server's front buffer. Now, if the user presses some key-kombo, Wayland renders only the first front buffer. Of course, there still needed to be done some hacking on mode setting (i.e. when the game starts), but technically this sounds feasible, doesn't it?

[drag]

Here let me explain something to you about XServers.

There are already lots and lots of X Servers.

A few off the top of my head are:

Xnest -- runs a embedded X server on your desktop.
Xephyr -- Replacement for Xnest that includes acceleration features.
Kdrive -- small X server
Darwin -- X for OS X
DMX -- distributed multihead X (with Chromium you can get distributed OpenGL acceleration, btw)
Xfree -- the default X server from X.org

So X.org provides the 'X Window System'. 'X Windows' as you probably know is a network protocol. Like HTTP.

So your X Server is equivalent to your Web Browser.
Then X Clients are equivalent to Web Servers.
X Clients talk to X servers using X Windows. Web Servers talk to Web Browsers using HTTP.

Now the only confusing part is that the 'X Server' part of X Windows is almost always on your local computer. So it's a bit opposite from the terms we normally use. This gives you a idea about how old X Windows is.

Anyways...

So the 'X Window System' is divided up into two parts:
DDX -- Device Dependent X
and then
DIX -- Device Independent X.

The X Server is the DDX stuff. X.org provides many different sorts of DDX's.

DIX is all the libraries and stuff that X.org provides that is used by various applications and toolkits to build X clients.


Soo....

If you think that Wayland is some sort of upstart or challenger to X.org then think again. That's just not how this works. Wayland is still going to have huge dependencies on X.org-provided stuff in order to work.

Anyways...

from his own blog:
http://hoegsberg.blogspot.com/2008/1...r-than-no.html

The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.

Sooo... It's not really a X Server at all and is not intended to be a replacement.

Instead if your going to be using it to run X Windows application you will have a X Windows server running, but with all the pixmaps rendered off-screen.. Then Wayland takes those pixmaps and sucks it down using it's own composted manager.

So it's a new sort of display manager that can use pixmaps displayed from a existing X Server.

Or something like that. Don't really understand all of it.

------------------------

Maybe the goal is to get a X Server running as a sort of daemon or something were you can then separate the X stuff from the Display stuff. Then you can possibly have detachable sessions (like using bash + screen) or have you application survive a driver crash or allow people to turn off the display directly and redirect it to other hardware or systems.

Or something like that. Like I said I don't really understand the point exactly.

[elanthis]

Drag: Wayland does replace the X server at one level of the stack. It can in time completely replace the X server: you don't have to run an X server at all with Wayland, unless you want to run existing X clients.

Assuming Wayland actually gets to a usable and complete point, and the design is proven solid, then developers can start porting apps (or toolkits, really) to Wayland's native protocol. Assuming all of your apps are ported, there'd be no need for you to have an X server running at all. You could fire up an X server on-demand for apps that need it, such as old closed binaries or old unported apps. That scenario is probably a good number of years away, though.

If you read the FAQ Kristian posted, that's all spelled out for you. It's pretty clear and informative.

The only thing I don't see answered (plz to answer Kristian kthxbai) is whether or not Wayland's protocol intends to support remote connections; if not, X would remain useful indefinitely for remote client support, but not for local clients.

The point of Wayland is essentially that 90% of what X does isn't necessary any more: all of the hardware setup is done in the kernel, all of the rendering is done in the clients, and all of the input events are handled by unified driver interfaces. Nested windows are considered harmful these days, the mandatory core X drawing protocol is essentially unused, and even RENDER is being replaced by clients doing rendering straight to pixmap buffers using GL. The only thing X is really needed for (aside from network support) is the functionality that Wayland provides, but Wayland does it without all the legacy protocol requirements. In the short term, Wayland is only useful as an X session multiplexer. Long term, it has the potential to make X unnecessary for most setups.

It's a really neat total redesign of the graphics stack in face of KMS/GEM/DRI2/EGL, and because X can so easily be run as a nested client, it can be done in a very transition-friendly manner so there's no "port or die" mandate like so many other software replacements force on developers. Pretty cool.

[hoegsberg]

Drag: Wayland does replace the X server at one level of the stack. It can in time completely replace the X server: you don't have to run an X server at all with Wayland, unless you want to run existing X clients.

Assuming Wayland actually gets to a usable and complete point, and the design is proven solid, then developers can start porting apps (or toolkits, really) to Wayland's native protocol. Assuming all of your apps are ported, there'd be no need for you to have an X server running at all. You could fire up an X server on-demand for apps that need it, such as old closed binaries or old unported apps. That scenario is probably a good number of years away, though.

If you read the FAQ Kristian posted, that's all spelled out for you. It's pretty clear and informative.

The only thing I don't see answered (plz to answer Kristian kthxbai) is whether or not Wayland's protocol intends to support remote connections; if not, X would remain useful indefinitely for remote client support, but not for local clients.

The point of Wayland is essentially that 90% of what X does isn't necessary any more: all of the hardware setup is done in the kernel, all of the rendering is done in the clients, and all of the input events are handled by unified driver interfaces. Nested windows are considered harmful these days, the mandatory core X drawing protocol is essentially unused, and even RENDER is being replaced by clients doing rendering straight to pixmap buffers using GL. The only thing X is really needed for (aside from network support) is the functionality that Wayland provides, but Wayland does it without all the legacy protocol requirements. In the short term, Wayland is only useful as an X session multiplexer. Long term, it has the potential to make X unnecessary for most setups.

It's a really neat total redesign of the graphics stack in face of KMS/GEM/DRI2/EGL, and because X can so easily be run as a nested client, it can be done in a very transition-friendly manner so there's no "port or die" mandate like so many other software replacements force on developers. Pretty cool.

That's a pretty good writeup of the major points in Wayland. As for the question about remote client support: no, I consider that outside the scope of Wayland. If you want remote rendering, Wayland is a good environment for running your remote display server such as X.org or an RDP server or similar, either full-screen or in a root-less fashion. Or somebody can invent their own remote display protocol on top of Wayland.

I've been thinking that maybe it's possible to implement a "remote compositor" that forwards the Wayland requets over the network to a remote display, but I haven't spent much time on that idea

[some-guy]

Would it be something like the compiz/dmx NOMAD patches?