Ray Strode

So during GUADEC I investigated autologin/followed by auto-locking the screen. The idea is a user may want to setup their machine such that they can turn it on, go get coffee, and come back to it all loaded (but locked).

One snag I ran into was that gnome-screensaver’s screensaver and the various components of the desktop (panel, splash screen, background, etc) would race to be on top of the window stack. The splash screen would pop up, then the screensaver would raise over it, then the panel would pop up and the screensaver would raise over it, etc. It was very flickery.

One solution to this is to use the MIT screensaver extension included with X. It provides a really-truely-always-on-top window that things like the splash screen and panel can’t ever raise over.

The screensaver extension has been rejected in the past for a few reasons:

1) We didn’t think we could get a fade in animation prelock since X maps the screensaver window automatically instead of letting gnome-screensaver do it

2) We didn’t think we could get separate screensavers running per head in a xinerama multihead setup since the screensaver extension only provides one window that covers the entire X screen (and so spans all the heads in xinerama setup)

3) We didn’t think X could reasonable know when the system was idle since there are more forms of user activity than input devices.

I wrote a little test program that demonstrates the first two issues are resolvable, and posted about it here:

http://mail.gnome.org/archives/screensaver-list/2007-July/msg00007.html

The fix for the first issue is to use a None background pixmap on the screensaver window so that when it gets mapped the contents of the screen don’t get erased and we can fade from there.

The fix for the second issue is to run the screensavers on child windows of screensaver window instead of on the screensaver window itself.