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

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>
<p dir="ltr">Thanks,<br>
--Jason Ekstrand<br></p>
<p dir="ltr">> Signed-off-by: Andrew Wedgbury <<a href="mailto:andrew.wedgbury@realvnc.com">andrew.wedgbury@realvnc.com</a>><br>
> ---<br>
>  src/screen-share.c | 1 +<br>
>  1 file changed, 1 insertion(+)<br>
><br>
> diff --git a/src/screen-share.c b/src/screen-share.c<br>
> index d3e3f05..b642072 100644<br>
> --- a/src/screen-share.c<br>
> +++ b/src/screen-share.c<br>
> @@ -1006,6 +1006,7 @@ weston_output_share(struct weston_output *output,<br>
><br>
>         if (pid == 0) {<br>
>                 /* We don't want anything circular */<br>
> +               setenv("WAYLAND_SERVER_DISPLAY", getenv("WAYLAND_DISPLAY"), 1);<br>
>                 unsetenv("WAYLAND_DISPLAY");<br>
>                 unsetenv("WAYLAND_SOCKET");<br>
><br>
> --<br>
> 1.9.2<br>
><br>
> _______________________________________________<br>
> wayland-devel mailing list<br>
> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</p>