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

[Jason Ekstrand]

On Mar 14, 2014 9:43 AM, "Andrew Wedgbury" <andrew.wedgbury at realvnc.com>
wrote:
>
> Hi Jason,
>
>
> On Tue, 11 Mar 2014, Jason Ekstrand wrote:
>>
>> >
>> > 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.
>
>
> Thanks, I'll take a look.

I pushed the update for wl_fullscreen_shell version 4 last night, so that
should be good to go.

>
>
>>
>> > 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)
>
>
> Yes, we're looking to support several different scenarios:
> 1) "user mode", where a logged-in user can start and stop screen sharing
from their session. 2) "service mode", where the screen is always shared,
regardless of who is logged in (or not).
> 3) "virtual mode", where we launch a separate virtual session for a user.
>
> In 2 of these scenarios, we would need to be able to start screen sharing
when the compositor starts up without requiring any interaction (because
the machine may be unattended in case 2, and because screen sharing would
be the only way of interacting with the session in case 3).

>From the compositor's perspective, 1 and 2 are more-or-less the same
because they both involve cloning the output.  The only real difference
there is how you pass the connection to the client.  Case 3 is a little
different because the compositor is fully running inside the VNC server.
Inside weston, if you want to run in case 3, you just start weston with the
wayland backend and point it at the VNC server and don't use the
screen-share plugin at all.  Also, I don't know if output management is an
issue here because the compositor can consider the VNC server as a
one-output piece of hardware.  Maybe we still want output management here,
but I'm not sure.

>
>
>>
>> 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.
>
>
> At the moment we tend to combine multiple outputs into one large
framebuffer for remoting, but even for this we still need to know the size
and position of each output.

Is that a requirement of VNC or is it just a figment of X using a unified
framebuffer stretched across all outputs?  In theory, the compositor could
just make you one big buffer if that's really how these things work
internally.

>
> Would it make sense for the fullscreen shell interface to have the
"add_output" request? You could have a separate "move_output" request, or
simply specify the size and position when adding. Then screen-share can
create outputs to match those of the real compositor and present surfaces
for them. I guess you'd also need a "remove_output" request.

I think it would if we think that output management is justified.
Obviously, not all fullscreen compositors will support add/remove_output
requests and we can come up with a way to advertise that functionality.
However, if we want the compositor to be able to do output management, I
think this is the best place to put it.

All that being said, I think I'd like to get things in weston as they are
before we try to add this.  I'm not 100% sure how to best do the output
management and I'd like to think/talk about it more so we get it right.

Thanks,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140314/bdd72673/attachment.html>