On Do, 02.04.20 11:30, Pekka Paalanen (ppaala...@gmail.com) wrote:

> > Thinking about this: it might make sense to revisit this
> > eventually... for example maybe instead of having gdm run all the time
> > and just listening to SeatAdded/SeatRemoved and CanGraphical property
> > changes and then spawn off a login UI for that seat, maybe we should
> > just add this behaviour to logind itself that it can spawn
> > compositor@$SEAT.service whenever this happens. That should be easy to
> > do and might be interesting for weston-like setups: i.e. you'd just
> > symlink the compositor@.service template to weston@.service and then
> > weston would get started automatically whenever a graphical seat shows
> > up. does that make sense? i kinda like the idea. it would solve all
> > your problems too, right?)
>
> Hi,
>
> yeah, that sounds attractive, but it has one problem: the idea of a
> usable graphics device might be different between logind and the
> compositor, like you explained.

True, but if implemented this way we could make weston exit if the
seat has nothing it can use. i mean, it's fine to start the compositor
in too many cases. it's more problematic to start it in too
few. i.e. if compositor@seat0.service exits cleanly when it decides it
can't handle the seat then that's totally fine.

> It would work for auto-login cases I guess, but I'm not sure about how
> well it would serve login managers. Wouldn't a login manager like GDM
> be still needed, but instead of listening to SeatAdded/SeatRemoved it
> would have to listen to login-UI actions? I'm really not the right
> person to evaluate that.

Well, gdm is a lot of things. it's both a seat manager and a greeter
implementation. my suggestion would be to move the seat manager to
logind, but leave the greeter in gdm. i.e. gdm would then have the
option to make compositor@.service a symlink to gdm-greeter@.service,
and thus just would need to take care of the greeter, but nothing else
anymore...

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to