Well, since revision 2038, we can consider this bug practically fixed. LightDM now adds/removes seats dynamically following logind SeatNew()/SeatRemoved() signals, and also listens on logind seats' CanGraphical property changes.
However, I think there's a last case that should be tested --- and it could be the most critical, although least probable, one: systemd boots too fast that lightdm service is started before main graphics device is loaded. In this case, seat0 would start as CanGraphical=no, and then switch to CanGraphical=yes after graphics device is ready. I'm not sure if lightdm at revision 2038 can handle this case. -- You received this bug notification because you are a member of Ubuntu Multiseat, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1190581 Title: Support logind's automatic multiseat feature Status in Light Display Manager: Triaged Status in “lightdm” package in Fedora: Unknown Bug description: Now that initial logind support https://bugs.launchpad.net/lightdm/+bug/930488 was released for LightDM, I'm opening this bug to request a step further: provide support to logind's automatic multiseat feature. I have absolutely no experience with D-Bus interfaces, but it seems that LightDM has its own D-Bus interface for seat management, so I don't know what would be better: replace it with logind D-Bus interface (if logind is present) or chaining both (e.g.: a logind's SeatNew D-Bus signal should trigger LightDM's SeatAdded D-Bus signal). Does it make sense? To manage notifications about this bug go to: https://bugs.launchpad.net/lightdm/+bug/1190581/+subscriptions -- Mailing list: https://launchpad.net/~ubuntu-multiseat Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-multiseat More help : https://help.launchpad.net/ListHelp
