[PATH wayland] allow to set server socket dir on a different directory than XDG_RUNTIME_DIR

Bryce Harrington bryce at osg.samsung.com
Fri Feb 6 16:57:12 PST 2015

On Fri, Feb 06, 2015 at 01:21:41AM +0100, Bettio, Davide wrote:
> Hello,
> Il 2015-02-05 19:31 Bryce Harrington ha scritto:
> >On Thu, Feb 05, 2015 at 11:14:09AM +0100, Bettio, Davide wrote:
> >>commit 68beb2b60f851c74b982b0a23da4bb1ce375efcf
> >>Author: Davide Bettio <davide.bettio at ispirata.com>
> >>Date:   Wed Feb 4 13:46:19 2015 +0100
> >>
> >>    Allow to explicitly set wayland server socket dir using
> >
> >Could you elaborate further on why you'd use this, as opposed to say
> >controlling XDG_RUNTIME_DIR, or even manually establishing the socket
> >file and specifying it via WAYLAND_SOCKET?  (Not that I'm arguing we
> >don't need this, but rather to make sure we can clearly explain why a
> >user would use one mechanism vs. another.)
> I think XDG_RUNTIME_DIR shouldn't be changed in more complex
> situations where a correct
> XDG_RUNTIME_DIR is required, so it might not be a viable option.
> According to the sources WAYLAND_SOCKET env var is not used at all
> on the server side so the problem cannot be
> fixed that way, unless we add support for it on the server side too.
> I think that using WAYLAND_SERVER_SOCKET_DIR makes quite easy to
> control the socket path by
> just changing the environment in several situations, this can be
> easily done using a systemd
> .service file for example or any bash script.

Thanks, that's a good rationale.  Again I'm not against adding an env
var for this, but just cognizant that every env var we expose is a new
interface that a user can (ab)use, thus needs to be individually
documented and test cases made.  And also the combinatorial
possibilities of combining this and other settings.

Since this code is applicable to all wayland compositors, not just
weston, I think it's doubly important that it be well documented
(inclusing mentioning the rationale you list above) and that it include
test cases.  So please include both in your v2, both for the server and
client patches.

> If we want to avoid to introduce any further environment var we may
> extend the semantic of WAYLAND_DISPLAY
> to accept also absolute paths (we just need to check
> WAYLAND_DISPLAY[0] == '/' for that) instead of introducing

That might actually be a bit cleaner solution.  Potentially would be a
bit more discoverable for users as well.  What do others think?


More information about the wayland-devel mailing list