moving rootless out of the server

[Jamey Sharp]

On 12/14/11, Antoine Martin <antoine at nagafix.co.uk> wrote:
> On 11/11/2011 08:59 AM, Jamey Sharp wrote:
>> Or use a modern implementation like x11vnc that uses COMPOSITE so it
>> doesn't need any server-side code at all. :-) That's the approach
>> we're trying to adopt in this new project.
> This approach sounds very similar to the one used by Xpra [1]: FYI it
> registers as a compositing window manager to capture the windows' pixels
> which it then forwards to potentially remote clients.

You and I definitely have related interests, although for different
reasons. I'm mostly interested in deleting code, but you're actually
doing useful new things. :-)

> Have you considered supporting this over the network?

Sure, remote clients have to work in order to fully replace XQuartz,
and you might as well allow the server to be remote too. Might even
get better performance if the server is on the same machine as the
clients instead of the machine with the display hardware. Keithp's old
papers on LBX and X network performance are probably insightful here.

> Wouldn't this be very useful in the context of Wayland?

I hope so! Once this project is done, I hope people reuse the code to
replace XWin and XWayland, and also to support rootless nested X.

> Are you also going to forward the bell, custom cursors, etc?
> (those still fit within X11 whereas supporting things like dbus /
> notifications is much more tricky)

Cursors are fairly important. I kind of hope the X bell works
eventually. It's possible that neither will be done by this team, but
we'll see!

> I have added memory mapped pixel transfers to Xpra recently [2]
> (obviously, this only works when the client and server are on the same
> machine) which improved performance significantly, although there is
> still too much memory copying going on. I suspect your solution will
> target zero-copy where possible?

Someday I hope to use DRI to share buffer objects directly between the
dummy X server and the magic rootless client. That requires a
DRI-capable version of video-dummy that only allocates off-screen
buffers, which is a little odd. And I don't know what AppleDRI
supports, for the OS X implementation.

In any case, that's probably out of scope for the current project. I
may push the team to use MIT-SHM if that looks easy enough, and that's
probably it.

> In any case, I am interested in your code as it may provide a
> better (and probably faster too) solution to some of the problems Xpra
> has to deal with. Please keep me posted.

Will do!

Jamey