[lug] X11 Protocol, migrating windows to remote displays

D. Stimits stimits at attbi.com
Mon May 19 16:27:18 MDT 2003


Michael D. Hirsch wrote:

> On Sunday 18 May 2003 07:01 pm, D. Stimits wrote:
>
> >Does anyone here know the X11 protocol well enough to say how easy it
> >would be to write an app (or modify xterm/konsole/gnome-terminal) to
> >allow migrating an X11 terminal to a remote display *after* the app has
> >started? I have an integrated app that I want to run entirely on one
> >machine, but I want the multiple windows it produces to be able to
> >migrate to/from a remote display. If I set $DISPLAY ahead of time, the
> >entire app goes to the remote display; even if I wanted that, it would
> >not allow me to migrate the window back to the original machine at a
> >later time. I'd like to be able to take an ID from a visible window or
> >widget, and tell X11 to redisplay on some other machine.
>
>
> I know enough to know it would be quite hard.  There are two parts to the
> difficulty.  The first part is the stateful nature of an X connection.
> The X server remembers a lot data and later X requests can refer to that
> data.  To migrate a window from one server to another means that you have
> to migrate all that data, too.  Another problem is the issues of 
> different
> bit depths and fonts.  X uses a particularly primitive color system in
> which each application needs to be able to support each different color
> depth.  Once it has connected to one server at one color-depth, it 
> will be
> unable to talk to another server at another color depth.
>
> I think the easiest way to do this would be to make a vnc server that 
> could
> serve just one window.  That actually doesn't sound that impossible.  It
> wouldn't actually send the native X protocol to the remote machine, but
> the effect would be the same.

This sounds to be about right. A vnc type server which can display just 
one window of a multi-window app would work perfectly, as long as it 
doesn't do this with every window of a multi-window app.

>
> You might look at the CCF project I was involved in at Emory U
> .  It's defunct now, but one tool we
> built was a virtual desktop that allows multiple users to share X
> applications.  If you are willing to restrict yourself to only running
> your programs inside a virtual desktop, then it might be of use to you.

This would probably be too much of a restriction for me.

> (There are a copule of other programs out there that try to do this.  As
> of 1999 when I left the project, this was the most advanced.)
>
> We did not implement the ability to make the applications display like 
> any
> other window in your desktop.  It would have been probably easier than
> what we did--displaying in a virtual desktop, a la vncviewer--but it did
> not fit our model of how it was going to be used.
>
> To do what you asked for, you you could start with our ccfx code and cut
> out the desktop parts.  Be warned that this is not a trivial task--there

Yes, I don't think I have enough motivation to do this. A second video 
card would be so much easier. But then I'd need a new monitor for the 
other machine.

> is a lot of poorly documented code.  Then, before starting the 
> application
> in question start your hacked ccfx and make the DISPLAY variable point to
> its port.  Then start you app.
>
> ccfx acts as an X proxy for the app, and it will display the app on your
> desktop.  When another ccfx connects they can both get the window.  The
> first user should, in principle, be able to close their view of the app.
>
> I think the single window VNC server would work better and easier.

I like the idea of a single-window VNC server, but I think I'll skip 
writing one...I'm in pain just thinking about it.

D. Stimits, stimits AT attbi DOT com




More information about the LUG mailing list