[RFC weston] remote access interface module

[Jason Ekstrand]

On Mon, Oct 21, 2013 at 6:36 PM, Andrew Wedgbury <
andrew.wedgbury at realvnc.com> wrote:

> 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.
>

It also has the advantage that it makes no difference to your VNC server
whether it is running a headless session or mirroring.  It simply acts as a
SHM-only compositor in either case.  (There may be a slight difference on
start-up for passing a live socket connection, but that's fairly trivial.)


> 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).
>

There should be no more complexity than your interface.  The "when do you
sample" part would be replaced with frame events.  Input pass-through isn't
that difficult (just look at compositor-wayland.c).  For output, it would
just write out to a SHM buffer that is passed to the VNC server.


> 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.
>

I don't think it will suffer from overhead much more than with your
proposed extension.  In the wayland protocol there is a concept of a
"frame" event that tells the client when what it just passed to the
compositor was actually shown on screen.  In the normal case, this allows
the clients to throttle drawing to the compositor's refresh.  In the case
of a VNC server, it would not send out *any* frame events if there are no
clients connected.  With a client connected, you would only send out frame
events after you have finished pushing the current frame to the client.  In
this way, the primary compositor (GNOME shell or whatever) can listen for
frame events and only snapshot on demand.  If you are working with a slow
internet connection, the VNC server may only send out a couple of frame
events per second (or fewer).  In that case, the primary compositor will
only snapshot one frame out of 10 or one out of 100.



>
> ---
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131021/549f16f0/attachment.html>