[PATCH wayland] RFC: Require WAYLAND_DISPLAY to be set instead of using wayland-0 as the default

Sjoerd Simons sjoerd.simons at collabora.co.uk
Mon Aug 17 00:29:18 PDT 2015


On Fri, 2015-08-14 at 11:22 -0400, Ray Strode wrote:

[ snip ]

> Still, I think this change is wrong headed.  We've been trying to
> cleave ourselves from environment variables for years in the default
> case.  Having to set this seems like a step backward.
> This means having to jump through additional hoops when using systemd
> --user sessions, it means
> having to jump through an additional hoop when running a program from
> a VT, and it means having
> to jump through an additional hoop when ssh'ing in to debug 
> something.

Agreed. Unfortunately i don't follow the list closely enough to spot
this patch earlier.

We've got several project/systems out there which do use the
combination of weston and systemd user session, which will get broken
with this behaviour change. Same for some of our automated testing
which logs into boards over serial and ssh and relies on programs being
able to connect to the default compositor without extra environment
variables.

> 
> if a user runs a program it should show up on the default display in 
> a
> clean environment.  save the environment variables for fringe cases
> like nested compositors.
> 
> The problem purportedly getting fixed gives this as a rationale:
> 
> > Now suppose you launch Weston while running the Gnome session. 
> > Suddenly, all of the Gtk+ apps
> > launched from Gnome will show up inside Weston instead. That's 
> > unexpected. There's also no good
> > way to prevent that from happening (other than perhaps setting 
> > WAYLAND_DISPLAY to an invalid value > when launching an app).

> It's wrong to say there's no good way to prevent programs from
> launching on weston.  This corner case, can be covered by setting the
> GDK_BACKEND environment variable.  edge cases should use environment
> variables not the default case.

The problem here is GDK_BACKEND would practically need to be set when
launching the graphical session. Which e.g. gdm could easily do but you
can't really rely on all display manager to do so. And ofcourse such
environment variables would need to be set for each toolkit, which
isn't great..

However a nicer/simple solution with weston would be to use e.g:
   weston -Snested-wayland 

Which will have the same effect as the committed patch (programs won't
connect to the compositor without having WAYLAND_DISPLAY set). 

If the corner case this patch was supposed to fix is indeed that
problematic potentially a better fix for that would be to have weston
not use wayland-0 as the socket if it's running nested?

> Furthermore, the commit says it's trying to fix a scenario where the
> user is logged into X, but the commit actually breaks X logins
> (because of the above log handler issue)!  That means it wasn't
> tested.
> 
> I don't think the commit is good idea at all, can we revert it ?

> XDG_RUNTIME_DIR is supposed to free us from other environment 
> variables.

Indeed! Even recent dbus can use that these days for its user bus, seem
s rather a shame wayland would go a step backwards here...

> --Ray
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

-- 
Sjoerd Simons <sjoerd.simons at collabora.co.uk>
Collabora Ltd.


More information about the wayland-devel mailing list