[RFC weston] remote access interface module

[Andrew Wedgbury]

Hi Jason,

I think I'm starting to understand. I can definitely see the advantage of not having to define new interface for remote access, as we could then only work with compositors that chose to implement this.

The part I'm struggling with is how the compositor would mirror its outputs to the VNC server's compositor. Wouldn't this mean adding a lot of extra complexity? (although I guess it makes sense if you have other reasons for doing so). 

Also, would there be much overhead in mirroring the outputs in this way? If there is then you'd probably only want to do it when you knew that there was a VNC client connected. For example, with my proposed interface, the VNC server would start requesting updates when the first client connects, and stop when the last client disconnects.

---
Andrew Wedgbury <andrew.wedgbury at realvnc.com>

----- Original Message -----
> From: "Jason Ekstrand" <jason at jlekstrand.net>
> To: "Andrew Wedgbury" <andrew.wedgbury at realvnc.com>
> Cc: "wayland" <wayland-devel at lists.freedesktop.org>
> Sent: Saturday, 19 October, 2013 2:12:44 AM
> Subject: Re: [RFC weston] remote access interface module
> 
> 
> 
> 
> 
> 
> Andrew,
> I've had ideas kicking around in the back of my head for a while now
> about how to do just this. However, my ideas have taken a
> substantially different route. I don't have any real problems with
> what you suggested (although I didn't read it in careful detail).
> What follows below is more of a counter-proposal.
> 
> Some time ago I proposed to the list a protocol for a fullscreen
> shell that only runs one client at a time. The proposal can be found
> here:
> http://lists.freedesktop.org/archives/wayland-devel/2013-August/010720.html
> . (As a disclaimer, I have since renamed it to wl_fullscreen_shell
> because that's a bit more accurate and because I do not intend for
> actual system compositors.) One of the purposes for this protocol is
> to allow you to nest compositors and use the Wayland protocol itself
> as an input/output abstraction. This way compositors (such as GNOME
> shell or Weston) can run on another system without having to have
> built-in back-end support for it. All that is needed is for someone
> to write a fairly simple compositor that provides
> wl_fullscreen_shell. This simple compositor could be, for instance,
> a VNC or RDP server. In particular this would allow any other
> compositor to run on top of Weston's backends because I have already
> implemented the fullscreen shell in Weston.
> 
> You may be thinking, "But I don't want to start the compositor inside
> my VNC server, I want it to mirror what's already on the screen." It
> wouldn't have be restricted to headless operation. Weston (or any
> other compositor) could spawn the VNC server and then immediately
> connect to it as a wl_fullscreen_shell client. (For security
> purposes, the connection could be established by passing an already
> opened file descriptor via an environment variable.) Instead of
> using that as the primary backend, Weston (or any other compositor)
> would simply mirror outputs to the VNC server. The assignment of
> seats would then be a compositor-configured thing (although I would
> vote for just adding the VNC seats).
> 
> The advantage of this method is that it requires very little
> repetition of protocol. If we run the VNC server as a client, we
> have to repeat most of the Wayland protocol only in the opposite
> direction. If we let the VNC server run as a server and the
> compositor as a client, we get all of the input handling, buffer
> passing, etc. for free.
> 
> Let me know what you think,
> --Jason Ekstrand
>