Disrecommend the use of display socket name wayland-0

Connecting by default to wayland-0 when environment variables
WAYLAND_DISPLAY/WAYLAND_SOCKET are not set can cause unexpected
connections when more than one session is being used. Specifically, if you
run a program from a non-Wayland context (over ssh, on a VT, in an X11
session, from a job scheduler), while some unrelated compositor is
listening on wayland-0, the program may connect to the compositor and
leave the user wondering what has happened.

This commit adjusts the documentation to clarify that the wayland-0
fallback is kept "for compatibility reasons", implying that in typical
use programs do not rely on it. The changes to the wayland-server
documentation (+ publican docs) briefly explain why compositors should
avoid providing wayland-0.

To avoid breaking existing software, the fallback to wayland-0 has not
been removed (and perhaps never will be).

As part of this change, the wl_display_add_socket_auto function has been
documented to describe its action as well as the recommended alternative
of connecting to the first available socket in the sequence wayland-1,
wayland-2, etc.

Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
This commit is contained in:
Manuel Stoeckl 2021-02-07 14:35:28 -05:00
parent ddf21afa6e
commit 8f518f958a
3 changed files with 50 additions and 5 deletions

View file

@ -92,9 +92,12 @@
<title>Wire Format</title>
<para>
The protocol is sent over a UNIX domain stream socket, where the endpoint
usually is named <systemitem class="service">wayland-0</systemitem>
(although it can be changed via <emphasis>WAYLAND_DISPLAY</emphasis>
in the environment). Beginning in Wayland 1.15, implementations can
is specified by the environment variable <emphasis>WAYLAND_DISPLAY</emphasis>.
(For compatibility reasons, if this environment variable is not set,
clients may try to connect to socket <systemitem class="service">wayland-0</systemitem>.
As this behavior may lead to accidental connections,
compositors are recommended never to set <emphasis>WAYLAND_DISPLAY</emphasis>
to this value.) Beginning in Wayland 1.15, implementations can
optionally support server socket endpoints located at arbitrary
locations in the filesystem by setting <emphasis>WAYLAND_DISPLAY</emphasis>
to the absolute path at which the server endpoint listens.