On Tue, 25 Nov 2014 09:02:22 +0200 Jussi Laako <jussi.la...@linux.intel.com> wrote:
> On 19.11.2014 12:56, Pekka Paalanen wrote: > > I have very hard time deciding if we should allow the environment to > > overwrite the server and client assumptions on where the socket is. It > > would be easier for me to accept new API functions that operate with > > absolute paths or existing fds explicitly, but those of course require > > both servers and clients to be written to use them. > > A bit tricky part in current Weston is case where you use > wayland-backend. In this case Weston is client to another Weston and in > addition server providing a socket to it's client. In this setup the > server is sort of proxy between lower level server and the client. > > Since both instances solely use XDG_RUNTIME_DIR, the wayland-backend > client weston is trying to connect to a socket there are create a new > socket with same name in the same place... > > The change is intended to allow a way to tell this second weston where > to look for the client socket and where to place the server socket. > Usually these two are not the same place... We don't have that problem anymore upstream. Now, if a socket file is already taken, Weston just tries the next one until it finds a free name, starts listening there, and exports WAYLAND_DISPLAY to its own clients accordingly. Before that was fixed, you could already use a command line argument to use a socket with a different name. However, all upstream cases will use XDG_RUNTIME_DIR, which probably is not appropriate for your use case, depending on how you actually start things. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel