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
