[PATCH weston v4 00/15] Add a fullscreen shell protocol

[Jason Ekstrand]

On Mar 11, 2014 11:36 AM, "Andrew Wedgbury" <andrew.wedgbury at realvnc.com>
wrote:
>
> Hi Jason,
>
>
> On Wed, 26 Feb 2014, Jason Ekstrand wrote:
>
>> 4) Screen sharing and recording.  The security discussion on how to allow
>>    clients to request screen sharing and things of the like is still
going
>>    on and I have no intention of solving that question here.  Most
>>    proposals for screen sharing and capture have been based on weston's
>>    screenshooter protocol which allows the screenshooter client to hand a
>>    surface to weston that weston then fills with the contents of the
>>    screen.  While this works for screenshots, there are a lot of race
>>    conditions involved in doing it this way.  People have also suggested
>>    screen sharing protocols.  However, these usually involve re-writing
>>    most of the wayland protocol in the other (client -> server)
direction.
>>
>>    For this reason, I propose that, instead of having complicated screen
>>    sharing protocols, the screen sharing or recording program simply act
>>    as a wayland compositor supporting the fullscreen shell protocol.  The
>>    primary compositor (the DE) can then spawn the sharing program and
>>    connect to it as a client.  This way we can use the normal Wayland
>>    protocol for communication rather than re-writing it in reverse.
>
>
> Thanks for this. I've been putting together a prototype using our VNC
server - I've implemented the required interfaces along with your new
fullscreen shell, and I'm launching it in place of weston from your
screen-share module. It appears to be working well.

Glad to hear it!  Not sure if it's helpful, but you might want to checkout
libwlb:

https://github.com/jekstrand/libwlb

I'm currently in the process of getting the latest version of
wl_fullscreen_shell implemented in it.  Unfortunately, it's not API-stable
yet, but I think it's getting close.

> One query - I notice you've added a "sprawl" option in compositor-wayland,
> which creates an output for every output in the fullscreen shell
> compositor. This makes sense in the "system compositor" use cases. But for
> screen capture you really want the opposite - i.e. the fullscreen shell
> compositor needs to create an output for each output of the real
> compositor. I guess we could just connect back to the real compositor and
> get the output configuration, but there still needs to be some way of
> connecting this up in screen-share. (At the moment I'm simply creating a
> single output in my fullscreen shell compositor)

Yes, this is an issue.  The wl_fullscreen_shell protocol only solves half
of the problem.  The other half is, as you've mentioned, is setting up
everything.  There are multiple reasons why this is a challenge.  First is
the question of how slave compositor (RDP or VNC server) gets launched
connected to.  One way to do this would be to develop a priviledged client
interface whereby a client can ask the server to connect to it for
screen-sharing and hand it the connection fd.  However, that's kind of out
of the scope for the fullscreen shell.  For the sake of my little demo,
I've made weston launch it.  (Note that the --width and --height parameters
that get passed should not be needed.  I have those in there because the
RDP backend for weston can't properly resize without crashing.  Ideally,
they would not be there)

The second issue is configuring outputs.  I don't know much about VNC or
RDP but I know that they have some mechanism for multiple outputs and we
would like to expose this.  One option would be to have the VNC server
connect as a client to the compositor.  If we go this route, you have to be
very careful that it doesn't dead-lock anyware because of the client-server
loop.  There are also a lot of race conditions there between the server
creating an output and the slave compositor creating one.  Even if we solve
those problems, this doesn't immediatly provide a mechanism for associating
the outputs that the VNC server sees as a client with the ones it provides
as a server.

Another possible way to solve this is to have an "add_output" request.
Obviously, many compositors won't allow this.  However, I am already
planning to add a set of capabilities flags so the compositor could easily
advertise whether or not this is supported.  If we did this, we would
probably also want to add some sort of move_output request to allow the
server to tell the slave compositor where the outputs are.  I talked to
Jasper a bit about this and I'm not 100% sure what I think of it.

I would be very glad to hear your input on this.
Thanks,
--Jason Ekstrand

> Andrew
>
> ---
> Andrew Wedgbury <andrew.wedgbury at realvnc.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140311/4a1f2ea7/attachment.html>