[PATCH weston] screen-share: Set new environment variable to identify server display

Jason Ekstrand jason at jlekstrand.net
Tue Apr 29 07:05:31 PDT 2014


On Apr 28, 2014 8:39 AM, "Andrew Wedgbury" <andrew.wedgbury at realvnc.com>
wrote:
>
> Some background on this: I am writing a fullscreen shell implementation to
> share Wayland displays over VNC, which can be launched in place of weston
from
> weston's screen-share module.
>
> In screen-share, variables WAYLAND_DISPLAY and WAYLAND_SOCKET are removed
from
> the environment when launching the fullscreen shell server to prevent it
from
> connecting back to the original server in a circular manner (since the
presence
> of these would cause weston to use the wayland backend).
>
> However, the fullscreen shell server may need to know the original
server's
> display name - to display a configuration UI, for example. This patch
saves the
> display name under a new environment variable "WAYLAND_SERVER_DISPLAY"
before
> removing it from the environment, so the fullscreen shell server can use
it if
> it needs to (the default fullscreen shell implementation in weston
doesn't use
> it currently). I picked the name "WAYLAND_SERVER_DISPLAY" as it is used
in a
> similar way to "WAYLAND_SERVER_SOCKET" in the screen-share module.

Andrew,
I think it's probably reasonable to pass the original server's socket
through to the subsidiary compositor.  However, we should not use
WAYLAND_SERVER_DISPLAY.  Right now, WAYLAND_DISPLAY and WAYLAND_SOCKET pass
the same thing: a way for a clident to attach to the compositor.  On the
other hand, WAYLAND_SERVER_SOCKET passes a way for the compositor to
connect to a client.  The client may not always be another compositor.  If
we use WAYLAND_SERVER_DISPLAY as a way for a compositor that has connected
to a client to connect back to the client (which we are implicitly assuming
is a compositor) as a client, I think we've mangled names and caused more
confusion than it's worth.

I think the better way to solve this problem is to just not unset
WAYLAND_DISPLAY.  As long as we launch weston with
--backend=rdp-backend.so, it will be forced to always choose the RDP
backend and the autodetection will never happen.  Having WAYLAND_DISPLAY
lying around won't hurt anything; it will just get overwritten when weston
opens it's Wayland socket.  This way we can solve your problem and avoid
the confusion of having WAYLAN_SERVER_DISPLAY and WAYLAND_SERVER_SOCKET
going in different directions.

Also, it would be worth looking into whether or not we need to actually
unset WAYLAND_SOCKET.  I don't think it will ever be set in the main Weston
process;  I just cleared it to make sure.

Thanks,
--Jason Ekstrand

> Signed-off-by: Andrew Wedgbury <andrew.wedgbury at realvnc.com>
> ---
>  src/screen-share.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/screen-share.c b/src/screen-share.c
> index d3e3f05..b642072 100644
> --- a/src/screen-share.c
> +++ b/src/screen-share.c
> @@ -1006,6 +1006,7 @@ weston_output_share(struct weston_output *output,
>
>         if (pid == 0) {
>                 /* We don't want anything circular */
> +               setenv("WAYLAND_SERVER_DISPLAY",
getenv("WAYLAND_DISPLAY"), 1);
>                 unsetenv("WAYLAND_DISPLAY");
>                 unsetenv("WAYLAND_SOCKET");
>
> --
> 1.9.2
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140429/7efca2c4/attachment-0001.html>


More information about the wayland-devel mailing list