What about remote X? [LWN.net]

What about remote X?

Posted Nov 4, 2011 20:23 UTC (Fri) by nwnk (subscriber, #52271)
In reply to: What about remote X? by wtogami
Parent article: Rawhide gets GNOME Shell for all display types

Will this Gnome Shell work for Remote X? This was one of the reasons why LTSP and http://k12linux.org has not supported Fedora 15+. If GNOME Shell will work for future remote X where the thin client hardware often lacks Composite then I will need to adapt LTSP to work with systemd of Fedora 17+.

This is a very confusing set of sentences. I'm going to try to sort them out, but please do correct me if I've misunderstood.

"Composite" isn't a hardware feature, it's an X server feature. If you can choose the X server running on your thin client, then it's something you can have. I'm going to assume you instead meant "hardware GL acceleration".

Remoting a composited desktop requires deciding where to put the compositor. If LTSP is doing XDMCP-style sessions (and I think it is, but it's been a while since I've looked), then your options are either to run the compositor on the thin client, or on the shared compute server. You probably want to run the compositor on the client, since that way it stands a chance of sharing an address space with the X server; if you ran it on the compute node then you'd be doing massive image transfers all the time.

But the compositor is also the window manager, and LTSP might currently run the WM on the compute node instead of on the thin client. If it is, that's already kind of a bad decision in terms of performance: you want window management to be low latency, so you shouldn't do it over the network.

So, sure, it's technically feasible to run gnome-shell like this. Will you be happy with the performance? I don't know, try it and see. There's plenty of low-hanging fruit in terms of performance work, see the Fedora feature page I linked to for details. llvmpipe's not intended to be a replacement for good hardware 3D drivers, but I suspect we can make it sufficiently fast for gnome-shell and similar compositors.

Related question ... earlier versions of Fedora worked with remote X for compiz in cases where the thin client hardware did support composite. But I noticed this is now broken in Fedora 14 and RHEL6. Any idea what changed?

to post comments

What about remote X?

Posted Nov 4, 2011 21:20 UTC (Fri) by wtogami (subscriber, #32325) [Link]

I don't know what "remote X for compiz" is meant to mean. But I don't have any reason to believe that we intentionally broke compiz between F14 and now; if it worked in F14 it still should. If it doesn't, bugzilla's -> that way. The entire GNOME2 desktop session including compiz last was confirmed to work Fedora ~12 with a remote X server and all traffic through a ssh tunnel. Performance was surprisingly good, even with animated flash on the sides of a spinning cube. It actually reduced the amount of bandwidth going over the wire between the X clients and remote X server. Fedora 14 and RHEL6 compiz fails with an error message. I don't have the error message handy.

What about remote X?

Posted Nov 7, 2011 7:19 UTC (Mon) by lindi (subscriber, #53135) [Link]

I use xpra (svn revision 266) and afaik that means I'm running a compositor on both the server and the client.

X11 clients to talk to a dummy Xorg on the server. xpra connects to this dummy Xorg and acts as a compositor. It then forwards updates to composition buffers over the network. On the client machine xpra just creates stub windows and fills their composition buffers with data that it gets from network. Finally the real compositor (compiz) can work with these stub windows.