Let env var override socket directory in libwayland-client?

[Pekka Paalanen]

On Tue, 25 Nov 2014 09:22:47 +0200
Jussi Laako <jussi.laako at linux.intel.com> wrote:

> On 19.11.2014 16:22, Pekka Paalanen wrote:
> > When a session compositor is started, you can already use
> > WAYLAND_SOCKET environment variable to pass an opened connection to it.
> > If your system compositor forks session compositors, no problem. If
> > something else starts your session compositors, you need a wrapper
> > program to pre-create a connection to the socket file in the shared
> > directory (that is not your XDG_RUNTIME_DIR) and then exec the session
> > compositor.
> 
> We are running system compositor under one special user session, in this 
> case user "genivi". This is normal session other than it is not visible 
> to logind (pam_systemd is not called).
> 
> Then, in our login manager (TLM), other seats are set to wait for the 
> system compositor lock file to appear before logging in default (guest) 
> user sessions. These are normal sessions visible to logind and weston 
> for each seat runs inside the user session. When user is logged out, the 
> weston instance is terminated and restarted for the next user session.
> 
> Passing WAYLAND_SOCKET environment from a user session of user X to 
> another newly created user sessions Y and Z is not very straightforward 
> operation... Also lifetime of the Y and Z vary and new sessions will be 
> spawned after one is terminated while the system compositor persists.

But you don't need that if you write a tiny wrapper program to be
executed instead of weston for the user sessions: you can even hardcode
there the special socket path it needs to open and then exec weston
with WAYLAND_SOCKET set.

Sounds like all the server side issues you tried to solve by
environment variables are already solvable in your system compositor,
right?

Getting session compositor to connect to the system compositor is the
last open issue in this series, isn't it?

Now the remaining question is, should libwayland-client use an
environment variable, that would allow overriding the directory for
where to look for socket files?

It's not strictly necessary, because one can always do that wrapper
program trick. However, that is also an argument that says that there is
no harm adding such an environment variable, because one can already
achieve the same thing.

There is one case where the wrapper program trick does not work: if the
session compositor or any of its forked children needs to open a new
connection to the system compositor, it doesn't work. I'm not
completely sure if that is a bad thing or a good thing.

Opinions, people?

I think I am slightly leaning towards adding such an environment
variable for libwayland-client.


Thanks,
pq