daemon: Move the waiting the session to have taken over the fb to gdm-local-display-factory
Commit 70861874 ("gdm-wayland-session,gdm-x-session: register after delay") delayed displays changing their status from PREPARED to MANAGED so that their status would not change until the session has had a change to install its own framebuffer and tell the GPU to scanout this new fb. Commit 74ee7771 ("local-display-factory: defer killing greeter until new session registers") uses this to avoid a flicker when transitioning from the greeter to the user-session by deferring the stopping of the greeter-session until the new display moves to the MANAGED state. But this only works when transitioning to a new user-session, when moving to an existing user-session (fast user switching) the display already is in MANAGED state and instead of deferring the stopping of the greeter commit 74ee7771 causes us to now never stop the greeter-session. This commit fixes this by starting a timeout when switching away from the initial-vt and letting that timeout stop the greeter-session. This commit removes the finish_waiting_displays_on_seat() call when the display's status changes to MANAGED, so that we still only have one code path stopping the greeter and not two. This means we also no longer need to delay registering the display. So this commit removes the code adding the delay (reverts commit 74ee7771). Note this commit uses a delay of 10 seconds, rather then 2 seconds. The transition to a new user-session takes about 8 seconds on my budget Apollo Lake based laptop (with SSD). Note this all really is a workaround, the proper solution for this would be able to tell the kernel to keep the greeter framebuffer around until a new framebuffer is installed. There is a patch to add a new unref_fb ioctl for this: https://www.spinics.net/lists/dri-devel/msg140912.html . We need to get this patch upstream and teach mutter to use it.
Showing with 41 additions and 36 deletions