<div dir="ltr"><div>David,</div><div><br></div>Looking at GDM debug and gdm-simple-slave.c source file, as well as "loginctl show-seat" output. I guess that GDM only requests user session activation for seats with CanMultiSession=yes, but currently systemd-logind still sets CanMultiSession=no for my non-seat0 seats.<div>

<br></div><div>Does seat_can_multi_session() heuristics need some improvement since generic multi-session was introduced?</div><div><br></div><div>I've applied your last patch. I confirm it solves my problem for now.</div>

<div><br></div><div>Thanks for all, and keep the good work!</div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">CANTATE DOMINO CANTICUM NOVUM<div>QUIA MIRABILIA FECIT</div><div><br></div><div>Laércio</div>

</div></div>
<br><br><div class="gmail_quote">2013/11/26 David Herrmann <span dir="ltr"><<a href="mailto:dh.herrmann@gmail.com" target="_blank">dh.herrmann@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi<br>
<div class="im"><br>
On Tue, Nov 26, 2013 at 11:45 AM, Laércio de Sousa <<a href="mailto:lbsousajr@gmail.com">lbsousajr@gmail.com</a>> wrote:<br>
> Hi David!<br>
><br>
> I just tested your patch, and unfortunately it didn't work. However, I guess<br>
> what could be the question.<br>
><br>
> If I understand correctly, your patch applies for the case we have no active<br>
> session at all in a non-seat0 seat. However, I do have an active session in<br>
> my non-seat0 seat --- the one GDM opens to show the greeter. The question is<br>
> that, when a user logs in at a non-seat0 seat, GDM (or whatever) should<br>
> activate automatically the new user session, sending the greeter session to<br>
> the background while it's in state "closing", as we have for seat0. In my<br>
> current setup, it doesn't occur: in a non-seat0 seat, the "closing" greeter<br>
> session remains active, while the new user session starts at background<br>
> (inactive).<br>
><br>
> If I activate manually the user session (loginctl activate <session>), the<br>
> converse occurs: when the user logs out, its "closing" user session remains<br>
> active, while the new greeter session starts at background (inactive).<br>
><br>
> Just for comparison: if I configure autologin for GDM (to avoid opening the<br>
> greeter session), or use multiseat-patched KDM (which doesn't open greeter<br>
> sessions), the user session starts at foreground, as expected, even without<br>
> this patch.<br>
<br>
</div>That gdm behavior is actually weird. It should explicitly request the<br>
new session to become active. There is no reason for logind to<br>
*assume* the new session should be activated automatically.. hmm.<br>
<br>
The appended patch reverts the new behavior. Can you give it a try? I<br>
actually cannot get gdm to pick up my additional seats.. and looking<br>
into the monstrosity called gdm-source-base I have no clue what it<br>
does. If you can confirm that this resets the behavior, I will apply<br>
it so we don't break existing setups.<br>
<br>
I will figure out something else for new multi-session capable seats.<br>
<div class="im"><br>
Thanks<br>
David<br>
<br>
<br>
diff --git a/src/login/logind-seat.c b/src/login/logind-seat.c<br>
</div>index b30c4ce..ca0e8d7 100644<br>
--- a/src/login/logind-seat.c<br>
+++ b/src/login/logind-seat.c<br>
@@ -413,8 +413,8 @@ int seat_attach_session(Seat *s, Session *session) {<br>
         seat_send_changed(s, "Sessions", NULL);<br>
<br>
         /* On seats with VTs, the VT logic defines which session is active. On<br>
-         * seats without VTs, we automatically activate the first session. */<br>
-        if (!seat_has_vts(s) && !s->active)<br>
+         * seats without VTs, we automatically activate new sessions. */<br>
+        if (!seat_has_vts(s))<br>
                 seat_set_active(s, session);<br>
<br>
         return 0;<br>
</blockquote></div><br></div>