What about remote X? [LWN.net]

What about remote X?

Posted Nov 4, 2011 17:41 UTC (Fri) by wtogami (subscriber, #32325)
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+.

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 17:49 UTC (Fri) by smoogen (subscriber, #97) [Link] (5 responses)

No idea.. time to test it since I think only LTSP uses the idea of remote X these days in a project form.. (yes I know people still do this.. I do.. but for a large project based on it I think it is LTSP). Everyone else seems to be using RDP and similar protocols.

[And now for the 40 posts saying, but you didn't count Y]

What about remote X?

Posted Nov 4, 2011 18:02 UTC (Fri) by wtogami (subscriber, #32325) [Link] (4 responses)

I have a longer term plan to make a next generation K12Linux that throws out LTSP entirely in favor of the fully Open Source components of kvm and the SPICE protocol. What is the status of SPICE in Fedora these days? Will remote USB ever be supported without the non-open source shim library?

What about remote X?

Posted Nov 4, 2011 19:36 UTC (Fri) by jonabbey (guest, #2736) [Link]

Ah, thanks for the reference to SPICE. We're trying to figure out a non-commercial means to do remote linux access for web browsing, and not having audio support makes it a significantly less attractive option than Windows and Remote Desktop.

What about remote X?

Posted Nov 4, 2011 19:43 UTC (Fri) by AdamW (subscriber, #48457) [Link]

Spice is pretty 'mature' by Fedora standards in that it's been there for two whole releases now. =) It's the default for newly-created VMs in F16, and it works very nicely for 2D graphics and sound. 3D passthrough isn't done yet. Hans de Goede has a very shiny set of improvements to USB passthrough he's working on which build on SPICE, which have USB 2.0 support (so more devices work and transfer speeds are way better - he has webcams working at full speed inside a VM) and a neat optional feature where if you plug a USB device in while the VM window is active the device goes straight to the VM, but if you plug it in while any other window is active, the device goes to the host.

What about remote X?

Posted Nov 4, 2011 19:48 UTC (Fri) by mindfaq (guest, #72880) [Link] (1 responses)

What shim library do you mean? Hans de Goede did some recent work on redirection of USB devices over the network for use with Spice/Qemu. This was also integrated into Fedora 16, some bits (for integration with libvirt) may still be missing though.

You can read about this on Hans' Blog:
http://hansdegoede.livejournal.com/

I am not aware that any kind of closed library is needed to use this. Instructions for building from source are available from Hans' Blog.

What about remote X?

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

This is good news. SPICE early 2010 when I last looked at it required a closed source library for USB redirection. It sounds like SPICE is now ready, and I will work on the next generation K12Linux soon. =)

What about remote X?

Posted Nov 4, 2011 20:23 UTC (Fri) by nwnk (subscriber, #52271) [Link] (2 responses)

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.

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.

What about remote X?

Posted Nov 4, 2011 23:39 UTC (Fri) by daniels (subscriber, #16193) [Link] (2 responses)

Err, what on earth X server are you using that doesn't support Composite? It's been enabled by default on every single X.Org server since 2004.

You might be referring to the lack of hardware acceleration for common Composite operations (e.g. accelerated Render, or in particular an accelerated zero-copy GL texture-from-pixmap path), but that's exactly what this post was about: enabling a fast software path for (eventually) zero-copy TFP.

What about remote X?

Posted Nov 5, 2011 0:11 UTC (Sat) by wtogami (subscriber, #32325) [Link] (1 responses)

Geode and VIA were the most common thin client video chipsets for many years. They were never capable of hardware accelerated composite needed by compiz.

What about remote X?

Posted Nov 5, 2011 0:19 UTC (Sat) by daniels (subscriber, #16193) [Link]

OK, so you're referring to hardware acceleration for OpenGL. Composite does not require GL: all the first compositing managers were built using only XRender. So the issue is Compiz's reliance on OpenGL, nothing to do with the Composite extension.

As I said earlier, the entire point of ajax's work (as you can see by reading the email) is providing a fast and competent software-only OpenGL stack (which we have never had on open systems: Mesa's classic swrast is very correct but also excruciatingly slow) using LLVM, so environments like GNOME Shell and Compiz can use GL without any hardware acceleration.