On Apr 28, 2014 8:39 AM, "Andrew Wedgbury" <andrew.wedgb...@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.wedgb...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel