Andy "Krazy" Glew is a computer architect, a long time poster on comp.arch ... and an evangelist of collaboration tools such as wikis, calendars, blogs, etc. Plus an occasional commentator on politics, taxes, and policy. Particularly the politics of multi-ethnic societies such as Quebec, my birthplace.

The content of this blog is my personal opinion. It is not that of my employer. See Disclaimer.

Photo credit: http://docs.google.com/View?id=dcxddbtr_23cg5thdfj

Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Wednesday, May 09, 2012

xpra

---+ rootless shareable and transportable X sessions.

For a long time I have been frustrated by VNC's putting all of the application windows in a big window for the X root. It always seemed to me that you could have an X server that kept all of the windows separate - perhaps by having an infinitely resizable root - which then allows the windows to be forwarded to the user's display (I think of that as a client, but in X terms it is a display server), and treated independently there.

I'm not the only one. Googling finds many people looking for "screen for X". I guess I betray my age when I admit that my desire for this predates GNU screen and VNC. I remember being happy when I encountered GNU screen's terminal multiplexer, since I had used similar tools elsewhere. (By the way, while I am at it: I recently started trying to use GNU screen, after a long lapse. One of my complaints is that GNU screen seems to be screen. I vaguely remember a terminal multiplexer that handled dumb terminals well enough, allowing you to connect separate terminal emulators, as well as other stuff.)

Anyway: screen for X...

I have looked at NX, xmove, etc., at various times, all with differing degrees of clunkiness. Nothing made mwe happy until...

Attach to the xpra server that is using local display number :7. Any apps running on that server will appear on your screen.

xpra attach ssh:frodo:7

Use ssh to attach to the xpra server that is running on machine frodo and using display :7. Any apps running on that server will appear on your local screen.

xpra start :7 && DISPLAY=:7 screen

Start an xpra server and a screen(1) session. If any of the applications inside screen attempt to use X, they will be directed to the xpra server.

xpra stop :7

Stop the xpra server on display number :7.

I.e. they assume that xpra is installed both on the server and on the client.

(Urg, confusing terminology. There are 3 important systems here: (1) the system where the xpra proxy server runs, (2) the system where the application software runs, and (3) the system where the display runs.)

This was a worry, since I often want to move applications to a system that may have X, but which may not have xpra on. E.g. Cygwin/X on my Windows PC. (I considered Winswitch for this, but it requires itself to be installed in too many places.)

I am happy to say that you do NOT need to have xpra installed on the display system. E.g.

14 comments:

xpra seems to be a proxy server. OK, but... if the xpra server is on a machine different than the application or the display, then if the xpra machihne goes down...

It would be nice if the X application could be redirected, without a proxy.

I have never heard of a protocol or application that could rewire itself to connect to a different target. But it would be nice.

It would be bad if all applications had to have code for this. A proxy like xpra makes the facility available to all applications. To avoid the proxy and make it retargettable pee, would have to have it in the protocol. Which amounts to saying that the application would do it - but one would hope that the library would do it for all.

"ssh -X system xpra attach :display" on a Cygwin/X system, followed by "xpra attach" somewhere else, leaves orphaned windows behind on the Cygwin/X display. I,e. the application moves to a new window on a new display, but the old window is not removed.

Experiment: xpra start :8 and :9.Started an emacs in :8, and make-frame-on-display :9 => same emacs spread across two xpra. Same shell buffer visited in both frame. :8 attached to VNC (on Windows), :9 attached to Cygwin/X server via ssh -X. Type "ls" on PC X window. 1 second to see results in other, VNC, emacs (via xpra, ...). 10 seconds before I see the result in the window I types ls into.

xpra slowness a big issue. Even though xpra in vnc is faster than xpra via ssh -X to cygwin/X, still too slow to want to work here if I really have to.

(Possibly partly because I am working over 4G LTE mifi today. May be better back when wired - but I need stuff to work when mobile.)

But, here is a way that seems to work well enough:

(1) I have 2 or more vnc4viewers, with multiple display sizes that can be changed using xrandr -s n.Different sizes to adapt to the different resolutions and orientations of monitors.

(2) I am still mainly an emacs user, so I run I run emacs normally with output to these vnc servers. Using make-frame-on-otherdisplay the single emacs can be used on multiple vncs, and also other X servers.

(2.1) I also have the emacs use or (or more) of my xpra sessions. So if the vncs go away or are naccessible or unusable for some reason, I can still connect to the xpra session and get the same emacs.

(3) I can run other stuff - xterms, etc - in xpra as appropriate. Typically want the xpra to be used for things like a console window, or an xterm in which I access lab hardware. In so doing, I can migrate these lab thingees.

xpra is 6/half-dozen wrt cnc for accessing lab hardwar4e:

a) xpra does allow using whatefver monitor I have - it is a pain when a shared lab machine vnc does not have the right resolution for where you are.

spreading emacs across multiple displays, VNCs and xpras, (a) gives emacs more persistence - if a display goes away, I can still use it (unless the display going away is associated with killing the emacs process itself). (b) givesd you the ability to "call" emacs to where you are, rather than having to send it to where you next want to use it.

Hi. Just wanted to clarify. Running xpra through -X or -Y is obviously slow because the X channel is run through SSH as-is.

One neat feature of xpra is in fact in using the client : everything is sent compressed which improves performances by a whole lot.

As a point of reference, i tried to watch videos in firefox over a double ssh tunnel and got almost 3 IPS through xpra on a weaky broadband connection. And then it would only spend about 60 kB/s bandwith if i recall correctly.

In contrast, simply running a few xterms over -Y in the same setup is enough to eat all my bandwith and make QoS deny everything else... Ooops..