[PATCH wayland] Revert "client: require WAYLAND_DISPLAY to be set"

Bill Spitzak spitzak at gmail.com
Mon Aug 17 09:58:22 PDT 2015


On Mon, Aug 17, 2015 at 7:48 AM, Ray Strode <halfline at gmail.com> wrote:

> Hi,
>
> > This reverts commit fb7e13021730d0a5516ecbd3712ea4235e05d24d.
>
> thanks, you've got my vote.
>
> Acked-by: Ray Strode <rstrode at redhat.com>
>
> --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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150817/372b25d0/attachment.html>


More information about the wayland-devel mailing list