wl_display_connect() falling back to wayland-0

[Pekka Paalanen]

On Wed, 11 Dec 2013 11:16:22 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> I certainly like that there is a fallback. The user should not have
> to set environment variables to get something to work.

Exactly. Users will not have to anyway. All the environment variables
are already set by "the system", unless the users themselves
deliberately do something unusual. It's called "shooting your own foot".

> In our software using X we always check if DISPLAY is set and if not
> set it to ":0". This is so the program just works even if the user's
> setup is wrong. (The primary reason though was because we need access
> to OpenGL even if there is no GUI running, which I assume (and hope)
> will not be a problem with EGL/Gl/Wayland, ie you can get access to
> this hardware if it exists, even if you are not allowed to talk to a
> wayland compositor).

You can access the gfx hardware by not using anything related to
Wayland, X, or any other window system. You can use Mesa EGL
with the null (or DRM/GBM) platform, IIRC. If you don't have Mesa, then
it should act like a normal GUI app, even if it does not create windows.

Picking a random display server when none is set up seems unexpected.

> I do think the proper solution is for gtk+ to check the environment 
> variables before calling it. Thus it can make up the rules for which
> one takes precedence if neither $WAYLAND_DISPLAY or $DISPLAY is set.

That is guaranteed to work, yes.

If no Wayland nor X env variables are set, where do you connect to? Ok,
the use of XDG_RUNTIME_DIR ensures that you will be connecting to only
Wayland servers running for the correct user. But you still don't know
if you should be connecting to which server in case there are several,
like in a nested case (e.g. if, say, kwin runs on top of weston, where
it is quite possible that weston has been modified to deny all other
connections, since its only job is to show kwin).

In the best case the difference would be only the error message:
"connection denied" vs. "no display server given". Of course, in my
example weston could be set up to not export WAYLAND_DISPLAY at all.
There are many kinds of solutions.

While I think it would be better to not have the default, I'm not sure
that can be changed anymore.

> 
> Jason Ekstrand wrote:
> 
> > How do you work around it?  What you got from Pekka is half right.
> > You need to check for both WAYLAND_DISPLAY and WAYLAND_SOCKET.  The
> > former is the catch-all "connect to this socket; it lives in
> > XDG_RUNTIME_DIR." The other is a mechanism for passing the client a
> > specific file descriptor that it is expected to use for it's
> > connection. This is usually used for launching trusted clients such
> > as the panel.
> 
> It might be nice if WAYLAND_SOCKET was instead a special value in 
> WAYLAND_DISPLAY. Or is there a reason a program would need 
> WAYLAND_DISPLAY if WAYLAND_SOCKET was set?

I think WAYLAND_SOCKET is like an ABI by now. Changing it would
possibly break many things. Also, how would you pick a special value,
that can be in an env var, but cannot be a file name? That sounds more
complicated than just having WAYLAND_SOCKET.

- pq