When you lock the screen on the first X session, you can click the button to create a new login. That works great. On the second display, however, when you lock the screen and click the button to create a third display, a confirmation window pops up, letting the user know that a display is already running that he/she may want to use. Problem is you can't get the mouse into that window. The mouse (and cursor) stay in the username/password dialog, making it impossible to use the new window. Upon further investigation, I've noticed that if you have a 2nd display running, and you try to start a new login from the 1st display, it does nothing. Well, it does almost nothing. The same window I mentioned above is created, it just gets created under the screensaver. As such, the owner of the screen has to unlock the screen before the new session can be accessed. This is a great feature that I've been waiting for -- it's virtually a necessity in our office. Let me know if I can give you any more information to help pin it down and get it fixed. Reproducible: Always Steps to Reproduce: Lock Display 1. Create a new Display 2. Lock Display 2. Create a new Display 3 from display 2 or Create a new Display 3 from display 1 Actual Results: Display 3 is never created due to problems with the confirmation window specifying other running displays. Expected Results: It should create a 3rd display. And after that, a 4th... Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r1, 2.6.11.10 i686) ================================================================= System uname: 2.6.11.10 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.6.12 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LC_ALL="C" MAKEOPTS="-j21" PKGDIR="/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/rc-overlay" SYNC="rsync://gentoo/gentoo-portage" USE="x86 X acl alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl eds emboss encode esd fam fbcon foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 guile imlib java jpeg kde ldap libg++ libwww mad mikmod motif mozilla mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline sdl spell sse ssl tcpd tiff truetype truetype-fonts type1-fonts usb vorbis xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS ==== I'm using binary packages built on the following machine: Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r1, 2.6.11.10 i686) ================================================================= System uname: 2.6.11.10 i686 Intel(R) Pentium(R) 4 CPU 1.70GHz Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distcc distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j23" PKGDIR="/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/rc-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acl alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl eds emboss encode esd fam fbcon foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 guile imagemagick imlib java jpeg kde ldap libg++ libwww mad mikmod motif mozilla mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png ppds python qt quicktime readline sdl spell sse ssl tcpd tiff truetype truetype-fonts type1-fonts usb vorbis xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
smells like an upstream bug to me, but i'll take a look
I had an opportunity to get my hands (really) dirty with this. Turns out it has nothing to do with xscreensaver code. In the configure script, it specifies a command that is launched upon clicking the button. That command is $ gdmflexiserver -l Unfortunately, the gdmflexiserver creates the aforementioned dialog when more than 1 display is currently running. I've searched gdmflexiserver documentation and simply cannot find a way to disable this dialog. So I wrote a patch to do it for me. The patch completely disables the creation of the dialog. This fixes xscreensaver's problem. I patched the xscreensaver ebuild to warn users that new-login is limited unless gdm is recompiled with new-login as well. I edited the gdm ebuild to apply my patch if new-login is set. I'm submitting my patches against the portage tree. I'm also going upstream with gdm to request that they create a command-line option to disable the dialog to avoid such draconian measures being necessary to get xscreensaver working correctly.
Created attachment 65634 [details, diff] Patch against /usr/portage/gnome-base/gdm This updates the gdm ebuild as mentioned in the bug.
Created attachment 65635 [details, diff] Patch for /usr/portage/gnome-base/gdm/files This is referenced in my updated ebuild.
Created attachment 65636 [details, diff] Patch against /usr/portage/x11-misc/xscreensaver This patches the xscreensaver ebuild as outlined in my comments.
gdm is the gnome herd's baby, so ccing them
FYI: #313197 at bugzilla.gnome.org
Created attachment 65800 [details, diff] Patch against gdm-2.6.0.9 Suggesting that a feature be destroyed got some attention upstream. They added a -s/--startnew commandline option to gdmflexiserver.c in CVS. I ported the changes to the current stable ebuild. Doing an epatch with this patch works like a charm. The dialog is dismissed with the appropriate command-line option.
Created attachment 65801 [details, diff] Patch against xscreensaver-4.22 And this patch is needed to get xscreensaver to play nicely. gdmflexiserver has to be called with a -s by xscreensaver. I can't say that I know anything about ./configure scripts, but this makes sure that the -s option is passed along to gdmflexiserver. On a slightly unrelated note, the original configure script says the default is "gdmflexiserver -l", but the result when the script is run is simply "gdmflexiserver". The arguments are lost during configure time. The -l is unnessecary. I'm going to bug upstream with xscreensaver so they know what behavior to expect from gdmflexiserver. This patch should be applied in ebuilds for now to allow this functionality.
GDM's changes from upstream have trickled down into stable ebuilds. xscreensaver can be configured via /etc/X11/app-defaults/XScreenSaver with the line: *newLoginCommand: /usr/bin/gdmflexiserver --startnew Thus, I consider the issue resolved.
