<div dir="ltr"><div>All of these arguments makes sense, so I guess I agree with reverting this change. I didn't know about the goal of reducing the number of environment variables. Also, the fact that wayland displays are per user makes it different from the X11 displays. Sorry for all the trouble! </div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Aug 18, 2015 at 12:34 AM, Sjoerd Simons <<a href="mailto:sjoerd.simons@collabora.co.uk" target="_blank">sjoerd.simons@collabora.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2015-08-17 at 09:58 -0700, Bill Spitzak wrote: > On Mon, Aug 17, 2015 at 7:48 AM, Ray Strode <<a href="mailto:halfline@gmail.com">halfline@gmail.com</a>> > wrote: > > > Hi, > > > > > This reverts commit fb7e13021730d0a5516ecbd3712ea4235e05d24d. > > > > thanks, you've got my vote. > > > > Acked-by: Ray Strode <<a href="mailto:rstrode@redhat.com">rstrode@redhat.com</a>> > > > > --Ray > > > Seems right to me question about the method of nesting Wayland in X > and X > in wayland; > > > The original problem of running Weston in a window in an existing > > GNOME > > X11 session and getting applications unintentionally launched into > > Weston can be circumvented by letting Weston use a non-default > > socket > > name, leaving wayland-0 unused. > > If Wayland is already running and using wayland-0 this would prevent > these > programs from using the X11 api. For instance if you wished to test > the X11 > api inside a Wayland session. Not really it just means you require a way to override the order in which they try their display backends (which e.g. for Gtk+ is possible). As Ray previously mentioned, keeping environment variables for corner cases is entirely fine. > Would it make sense that if DISPLAY is set and WAYLAND_DISPLAY is not > set, > that a program capable of doing both should prefer the X11 api? This > would > mean that I could force use of the X11 api by unsetting > WAYLAND_DISPLAY. That seems rather fragile (and really up to the toolkit/program to implement, wayland can't know if the program supports X11). > This will require changes to the client (unless the wayland connect > was > changed to fail in this case, which I suspect is not a good idea) > which > probably explains why the idea of renaming the socket was suggested. > > As for the patch, I agree. The Foundry software would check if > DISPLAY was > not set, and set it directly to ":0", so that X would work always (it > did > not open the display by name because it wanted to fix child programs > as > well). This was commercial software and this was demanded by qc. So > effectively they wanted X11 to work without an environment variable. the problem with DISPLAY is that it's not namespaced per user, so if you have two users logged in on an X graphical session one will have e.g. DISPLAY=:0 the other DISPLAY=:1. Because of that defaulting to :0 on X isn't a great idea on multi-user systems. However for wayland, the sockets are namespaced per user as they reside in their respective XDG_RUNTIME_DIR, which means two people can start a graphical session and both use wayland-0 for their compositor just fine. <div class="HOEnZb"><div class="h5"> -- Sjoerd Simons <<a href="mailto:sjoerd.simons@collabora.co.uk">sjoerd.simons@collabora.co.uk</a>> Collabora Ltd. </div></div></blockquote></div> </div>