GNOME Bugzilla – Bug 313197
gdm flexiserver Open Displays dialog incompatible with xscreensaver
Last modified: 2005-08-15 18:03:07 UTC
Please describe the problem: xscreensaver recently added a "new login" button feature, improving the multi-user environment. When a screen is locked, a user can click "new login". The result is that gdmflexiserver is called. This works great for the second display. However, when two or more displays are running, gdmflexiserver draws an "Open Displays" dialog before it creates a new display. Problem 1 is that because xscreensaver still has the screen locked, the new user is unable to interact with this dialog, thus a new display is never launched. It does not appear that there is any way at the command line to start a new server without confirmation. Thus, when using xscreensaver with new-login, I've had to patch gdm to disable that dialog. I'm not skilled enough in C to implement said option on my own, but I was able to out-right disable the dialog. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 50561 [details] [review] Patch against the gdm 2.6.0.9 tarball This replaces the run_logged_in_dialogue function with return;
Unfortunately this fix is not appropriate. The GUI you have disabled is the mechanism users can switch back to a previous session without having to use Ctrl-Alt-FuncKey (which cannot be depended upon since it is an Xserver feature that can be disabled). The right solution might be to add a new command line option that can be passed to gdmflexiserver so that it knows the user wants to create a new session and avoids putting up the dialog. This means that the command run by Xscreensaver will need to change slightly. If I fix gdmflexiserver to accept such a command-line option, can somebody fix Xscreensaver too? Hopefully the command to run in Xscreensaver is configurable. If Xscreensaver sets up any environment variables, Xserver atoms, or other things that could be used to recognize that Xscreensaver is running, these interfaces could also be used to identify not to pop-up the dialog instead of a command-line option.
Awesome. I new my fix was totally inappropriate. But it worked. The command line option would be the ideal fix to this problem. To get xscreensaver to play along, those developers would simply need to edit their ./configure script (I was playing with this earlier today -- able to call gdmflexiserver with various arguments, none of which prevented the dialog from being displayed). Thanks for the prompt response.
I fixed gdmflexiserver in CVS head to support the --startnew option which just causes it to always start a new server and avoid the dialog. Please test this with xscreensaver and let me know if it works. Closing.
Created attachment 50633 [details] [review] Patch against gdm-2.6.0.9 I used your code to create a patch against 2.6.0.9 (because it's stable with gentoo and I'm working in a production environment). I'm attaching my patch. On line 313, you do response = RESPONSE_OPEN_NEW_DISPLAY; to catch the -s case. Then in the switch on 376, you call gtk_widget_destroy (dialog); However, with -s, the dialog is never created. It segfaults for me when this code gets executed. The back trace led me to the above problem. My fix is on line 313, return instead of setting response.
I'm reopening. See attachment.
Fixed in CVS head. Please retest. Thanks.