Thanks for working on this. I think we need to make login1.c a class now because it's getting too complicated, i.e. Login1Service or similar. That will solve the issue of the SeatAdded and SeatRemoved code in lightdm.c being complicated because this would then be replaced with GObject signals i.e. seat-added that has a Login1Seat object in it. Let me know if you need any help with this because I can set up some boilerplate code if you like.
For tests we basically need to add all the new login1 d-bus interfaces to tests/src/test-runner.c. Then we need to make some test scripts that try a few of these cases. This should be the same as copying tests/scripts/multi-seat.conf and adding the appropriate prompts to our fake login1 service. Again, let me know if you want me to set up the boilerplate code for this. I think we should just drop all the existing manual seat code. If you detect logind running, then that is the only information that is used to decide what seats are present. If logind is not running then we just assume there is one local seat, "seat0". Configuration for each seat should be in "[Seat:SEAT-NAME]" where SEAT-NAME is the XDG_SEAT name for the seat as provided by logind. If necessary we can add a manual method for adding seats and/or use ConsoleKit if it is present. This is the same strategy we do if we don't find AccountsService (i.e. use /etc/lightdm/users.conf instead). I think if we try and keep the existing manual seat system it will be complicated and compromise the logind implementation. And I suspect that most actual multi-seat deployments will be using logind. -- https://code.launchpad.net/~ubuntu-multiseat/lightdm/automatic-multiseat/+merge/229682 Your team Ubuntu Multiseat is subscribed to branch lp:~ubuntu-multiseat/lightdm/automatic-multiseat. -- Mailing list: https://launchpad.net/~ubuntu-multiseat Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-multiseat More help : https://help.launchpad.net/ListHelp
