Dual X Servers Running Side-By-Side With Wayland

[quintesse]

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.

The age of the X Windows system has nothing to do with it because the terminology makes perfect sense. On your local system exists a process that is able to draw windows, lines, icons, text and all that stuff. And it allows others to connect to it and ask it to draw things on the screen.

Normally anything that provides a service by allowing others to connect to it is called a "server" and the ones doing the connecting are called "clients".

You may associate a "server" as something remote and far away and a "client" as something that runs on your local system but in many cases that is just wrong.

Just see your screen as the "server" and the applications you start as the "clients" "asking the server" to paint their windows.

[elanthis]

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.

Well, RDP sucks nuts for over-the-Net connections or for remote real-time rendering jobs. I wouldn't mind either just keeping X or having some new protocol so long as one binary can run both locally and remotely without modification. That is one very clear advantage of the X setup -- your apps just work in both configurations and even get full GL acceleration over the network thanks to GLX.

Granted, these days, the only reason I personally use remote X at all is for running a handful of sysconfig tools that the developers decided to make GUI-only. :/ (And for making Windows-using friends jealous when I run Quake on my quad-core desktop at home while displaying/playing it on my laptop at their house.

Thin-client setups though really need a solid, bandwidth-efficient, extensible, low-overhead, fully-accelerated, low-latency, no-setup rendering protocol. Given the apparent future adoption of GL at all levels of the rendering stack, maybe all we need is just a compressed X-less GLX plus a basic input/event mechanism.

[elanthis]

Actually, a few more questions for you Kristian. First, how do you think things like drag-n-drop and menus should be handled? X right now uses mouse/keyboard grabs, which I despise with all my being. That approach means that when an app has a grab and deadlocks (like Evolution seems to do one out of 20 times for me when trying to drag-n-drop messages between folders), the whole damn X session becomes completely and utterly unusable until I switch to a VT and SIGKILL the app. Will it possible in Wayland to implement those features, as well as things like windowed-games that want to track mouse position even when it's outside the window, without grabs?

If not, would it at least be feasible to detect deadlocks (similar to the usual "this app is not responding" detection certain WMs have) and break the grab, and/or allow something like ctrl-alt-del or ctrl-alt-bksp to break it? Ideally there should be a key combination that always displays a non-overridable safe system dialog like Windows has, so you always have a way to take back control of the machine in the face of a badly behaving application, even if it's full-screen and has all input grabbed and is locked up (like a game). That's certainly possible in X with a little work. My second question is whether or not you already have plans for Wayland to support such a facility.

The third question is: do you think Wayland should lock itself in memory (which may require root or partial-root privileges) so it never gets swapped out and thus cause the whole session to lock? Another problem related to dead-locked apps is apps that consume all the RAM and cause everything -- including the WM, X server (including input code), VT login processes, and so on to all be swapped to disk. Even switching to a virtual console to kill the app can end up being impossible, because it takes forever for X to switch VTs, forever to wait for the login process on the VT to be paged in, forever for the bash session to start, and then forever for kill/killall to start. Depending on the specific behavior of the app, the OOM killer might not ever kick in, so there's apparently no way to recover. I've had instances where I could manage to get to a logged-in console but killall couldn't manage to start even 2 hours after I typed in the command. Older versions of Firefox have done this to me on more than one occasion, as have a couple games.

Thanks!

[drag]

Well then I wouldn't consider it a 'replacement' for X so much. That implies replicated functionality. A 'alternative' to X would probably be more accurate.

At least that's how I got about defining terms when I talk to people about replacing Exchange servers or other such things. Like I can say that: "Linux can offer lots of alternatives to using Exchange, but right now it offers no real replacement for it.. but Openchange (not to be confused with openexchange) is in the works so that you can eventually use a Linux server to provide a drop in replacement."

That sort of thing. It's a bit nitpicky, I know.

But I think people would be more interested in it as a completely new graphics system for Linux as opposed to a 'just a new X server'. We already have lots and lots of different X Servers.


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



Hell, in light of what you guys were talking about it may be time for a entire new X Windows protocol. Something that's updated.

The network functionality of X is much to valuable to leave it up to 'use vnc' or stuff like that. X is a much better performer nowadays over the network then it used to be. Just look at LTSP. And it would suck to force toolkit makers to support multiple backends to get the benefits of Wayland without sacrificing good thin client support.

For example I'll setup a 1024x768 Xephyr display to run remote Gnome Desktop over encrypted SSH tunnel. This thing is _snappy_. It's a much better performer over (a rather slow, lossy, and overgrown corporate network, from one building to another) 100Mb/s ethernet connect then Rdesktop is able to do over localhost to Windows running on a VM. (with Rdesktop itself performing much better then the VNC-based terminal that I get with Fedora's virt-manager)

I also noticed that with Opengl applications and AIGLX I could play full screen (like 1280x960 or so) Return to Castle Wolfenstien over (my faster home network) 100Mb/s connection, even with ssh encryption. Like 20-40fps. Blender worked and all that. This was a while ago when AIGLX first came out. Over the same connection Gnome and KDE apps had more noticable lag.

If like your saying that X apps are barely using X aymore, or at least using it less and less, then it may be a good time to redesign X protocol to make it easier to compress and avoid the ping-pong type client-server behavior that causes lots of performance issues over higher latency connections.

It could be something that could be dramatically simplified over what is now.

The security of X is one huge thing that is holding it back also. This is something that could be addressed. Especially when you move X completely off the hardware.

Then people could keep the 'legacy xfree'-style server for backwards compatibility with older protocols.


Just a suggestion.

[elanthis]

I also noticed that with Opengl applications and AIGLX I could play full screen (like 1280x960 or so) Return to Castle Wolfenstien over (my faster home network) 100Mb/s connection, even with ssh encryption. Like 20-40fps. Blender worked and all that. This was a while ago when AIGLX first came out. Over the same connection Gnome and KDE apps had more noticable lag.

If like your saying that X apps are barely using X aymore, or at least using it less and less, then it may be a good time to redesign X protocol to make it easier to compress and avoid the ping-pong type client-server behavior that causes lots of performance issues over higher latency connections.

The lag in KDE/GNOME apps can be from a combination of things; usually not the protocol itself. Certain toolkit rendering engines try to hardware accelerate everything they can but then fallback on software rendering for things they can't -- so you end up having to copy buffers back and forth over the network (not to mention hardware buses) multiple times to render things. The roundtrips are also not really the protocol's fault. The xlib library requires a lot of technically unnecessary roundtrips, for which xcb was created to fix (no need for a protocol change). Some themes or widgets also just do relatively dumb things with rendering, such ss trying to grab copies of buffers for things that could be done in a copy-free manner (especially on modern hardware w/ shaders).

In the face of networked apps -- and even to a lesser extent all apps -- it is generally better to either render _everything_ in the hardware or to render everything in software. Otherwise you have to copy buffers back and forth, and that slaughters performance in oh so many ways.

The security of X is one huge thing that is holding it back also. This is something that could be addressed. Especially when you move X completely off the hardware.

How so? If you're talking about requiring root access, that's caused by the driver model. X on Wayland would not require root access, nor would X with an update DDX/kernel interface.

If you mean controlling which apps can talk to other apps with the protocol, I believe that's what XACE is supposed to tackle. I have to yet to evne find a specification for XACE online, though, so I'm unsure...

Then people could keep the 'legacy xfree'-style server for backwards compatibility with older protocols.

"legacy free" and "backwards compatible" are two entirely contradicting terms.

[drag]

In the face of networked apps -- and even to a lesser extent all apps -- it is generally better to either render _everything_ in the hardware or to render everything in software. Otherwise you have to copy buffers back and forth, and that slaughters performance in oh so many ways.

Well at least Gnome stuff is much better now then the time period I was talking about then.

I had a discussion once about gnome-terminal vs xterm and performance and people were telling me that xterm would provide better or more consistent performance then gnome-terminal because it was closer to the x protocol or something like that. Less gtk bullshit getting in the way or whatever. I did benchmarks and gnome was obviously using tricks with text rendering for remote X apps and whatnot and gnome-terminal easily trounced xterm. Wasn't even a comparison.

Like I mentioned up there it's my current experience (running Fedora 10 on my laptop) that running a Xephyr-based nested X server with gnome-session (from a CentOS 5.2 system) over AES128-encrypted SSH tunnel over 100Mb/s connection is able to provide a much better 'feel' and responsive interface then Rdesktop running over "localhost" (well not loop-back, but over virtual network) to a Windows VM.

This is a KVM-based Windows VM that was created and managed using Fedora's virt-manager stuff.

In turn I am using Rdesktop becuase it performed much better at bigger sizes then the VNC stuff that is provided by default by virt-manager to handle graphical consoles.

And KVM and the virtual network is no slouch either, mind you.


It may or may not be worth your time to do what I am suggesting. Or it may be something that other people need to do.

But I figure with lessons learned with NX and whatever the GTK/Gnome guys are doing, plus the lack of usefulness for the majority of functionality that X protocol provides then maybe it's just time for a new, much streamlined X protocol.

How so? If you're talking about requiring root access, that's caused by the driver model. X on Wayland would not require root access, nor would X with an update DDX/kernel interface.

I am talking about X as the network protocol. If you run X outside of a ssh tunnel then it can easily get sniffed. It's a chronic issue and if you every tried to run a nested X server without the '-ac' switch to disable the access controls then its very difficult to get working.

If like you guys said that X protocol requires a lot of extra horseshit that nobody uses anymore then it's probably time to update the X protocol. Maybe make it X12 or something.

It's been done in the past, obviously.

"legacy free" and "backwards compatible" are two entirely contradicting terms.

Ya read it wrong. Legacy xfree-style X server. As in X11R6 compatible. Which is what we all use now.

'legacy xfree'-style server

X is very crusty and one of the big things is backwards compatibility. So you just shovel that off to the side and modern apps would use the (currently imaginary) X12 protocol that (my imaginary) Wayland-style system would support natively.

[drag]

I donno.

I mean remote X isn't something that is critical for desktops. Never was. So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.

I like X network functionality. I don't give two squats about the actual nature of the protocol itself, though.

But one thing to consider is that from X's original conception in 1983-ish to 1987 there were 11 different versions of the X protocol. We have been using version 11 for 21 years now. One of the big reasons (according to wikipedia) for the change from X10 to X11 was to make it more 'hardware independent'.

Also there is functionality present in competitors... like with Vista your able to have disconnect between the applications and the display. If you log into rdesktop, for example, you can view and interact with whatever application you had left open on your last session.

Also with Vista if your display crashes from buggy drivers (or whatnot) then the display will go to black, Vista will attempt to restart the graphics stuff, and then if it works you can log back into your previous session. For lots of users if their display drivers crap out then all they see is a brief black screen.

So it would be nice to have that same sort of functionality for Linux.

[quintesse]

I mean remote X isn't something that is critical for desktops. Never was.

Uhm, you probably weren't alive yet or too young to remember the time of the dumb and thin terminals? When I started studying things were all done remotely. The idea that some time you would have multiples of that power in your mobile phone was pure science fiction

So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.

Things are not fast and wonderful right now? I don't see X apps being outperformed by their Windows counterparts and we're able to do Vista-like stuff with 20+ year old technology? It seems be doing pretty well IMHO.

That doesn't mean I don't think we should take a look at bringing all of this technology into the new millennium, but lets not throw out the baby with the bath water.

[Ex-Cyber]

I mean remote X isn't something that is critical for desktops. Never was. So if getting rid of it completely would result in something that was fast and wonderful then I am all for it.

People who have lurked in the Unix/Linux scene long enough to have seen this argument a dozen times will take this statement to mean that you don't support getting rid of remote X (even if that is denying the antecedent ).

[drag]

Well I like the remote features of X. I think it's very cool.

There are things that could make it very more cooler.. like the ability to detatch and re-attach clients to other X servers and stuff. You can do that with Sun's X terminals, for example. Also with Windows you can attatch remotely using rdesktop and get access to the apps from your last session. Also with Vista if the display/graphics drivers crash for whatever reason the system resets the graphics and you don't loose your session either.

I mean I use remote X every day. I like that feature, I don't care much about X either way. If the protocol can be updated or replaced to make things simplier then that would be wonderful.

.
Things are not fast and wonderful right now? I don't see X apps being outperformed by their Windows counterparts and we're able to do Vista-like stuff with 20+ year old technology? It seems be doing pretty well IMHO.

Well I didn't mean it like 'fast' as in raw performance, but of maintainability and whatnot. 'Fast' as in the ability to get things done in a timely manner and having good fast performance. (X isn't wonderful right now, though. )

There are only so many hackers out there with the capabilities of working with X and graphics. If simplifying things means getting rid of X completely and that means easier times for developers.. then I support it.

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

The only thing I don't like about Wayland is the "oh we'll support X through composited interface, but toolkits like GTK can be ported to support it natively".

This is the sort of 'multiple backend' thing that plagues Linux sound stuff. Like "Oh, if Alsa doesn't work use OSS" type things.. or Amarok supporting a dozen different audio APIs. It's a mess and each 'choice' brings with it's own advantages and broken functionality. Confusing and difficult and time consuming.

The problem is that in order to get that extra layer of abstraction too support two sorts of backends like X vs Wayland means a lot of extra work. Plus unless you can get functionality effectively the same on both systems then that means that your going to get stuck with the lowest common denominator.. If GTK was to get popular on Wayland then that means that unless new features are supported both in X and in Wayland then that means that GTK won't be able to benefit easily from improvements in either one. It'll get stuck in between them and only using functionality that is present in both environment.

So if your going to create a alternative you need to make sure that alternative has the capabilities of replacing X completely. Sure keep a X server around for compatibility with legacy applications and whatnot, but make Wayland nice enough and with the required functionality that people need from a GUI system so all future developments happen on that system.

Something like that.

Needless layers of abstraction really hurt Linux and makes things more difficult. So either work on replacement of X completely (or a updated XR12 protocol) and hope it takes off, or encourage people never to program in Wayland directly except for special purposes and just use it for managing the display. Something, to avoid the division.