xscreensaver can be compiled with a new-login button, which recognizes both gdm and kdm. However, if the appropriate executables cannot be found at compile time, the new-login button will not be compiled in, despite the use-flag being active. Enter lightdm: It provides its own replacement for gdmflexiserver, located at /usr/libexec/lightdm. Unfortunately, this is not picked up by xscreensaver's configure script. To make it do so, there are two solutions: 1) Alter lightdm ebuild to put the file to a directory in $PATH, or create a symlink or whatever; at least I believe this should work. 2) Alter xscreensaver ebuild to recognize lightdm's gdmflexiserver. I decided to do so, and will post the necessary changes here. Reproducible: Always Actual Results: xscreensaver is not compiled with new-login button. Expected Results: xscreensaver is compiled with new-login button, using lightDM's gdmflexiserver replacement.
Created attachment 294547 [details, diff] Add entry for LightDM gdmflexiserver to configure.in
Created attachment 294549 [details, diff] Patched xscreensaver-5.15.ebuild to make it apply the changes.
Please send this patch also to jwz@jwz.org (upstream) so it can be included in 5.16. Also CCing him on this bug just in case.
I see a problem with this patch and actually with the configure of xscreensaver. I have kde installed as I am using some of its programs, so kdmctl is installed as well. I am using lightdm to login, but xscreensaver still try to use kdmctl. (Error: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket')
I think it would be best if xscreensaver had a ./configure flag like --enable-new-login-default= which would accept args like lightdm, kdm, or gdm and set the default If nothing is set, default to eg. gdm And then search for all 3 in order at runtime, first the default one if configured, and then the other 2 I realize this needs quite a bit of patching...
configure --with-login-manager=/what/ever
I presume this bug has to be handled by upstream developers first
(In reply to comment #5) > I think it would be best if xscreensaver had a ./configure flag like > --enable-new-login-default= which would accept args like lightdm, kdm, or gdm > and set the default > > If nothing is set, default to eg. gdm > > And then search for all 3 in order at runtime, first the default one if > configured, and then the other 2 I personally would solve it like this: -add a new function to /etc/init.d/xdm, e.g. control_command, which tells the control command of the currently running xdm or false (if not existing) -make xscreensaver's configure, use '/etc/init.d/xdm control_command' as default_display_manager.
> I presume this bug has to be handled by upstream developers first Not necessarily. Looking at the xscreensaver package, I found out that you can configure the login command in /usr/share/X11/app-defaults/XScreenSaver: ! This command is executed by the "New Login" button on the lock dialog. ! (That button does not appear on the dialog if this program does not exist.) ! For Gnome: probably "gdmflexiserver -ls". KDE, probably "kdmctl reserve". ! *newLoginCommand: /usr/libexec/lightdm/gdmflexiserver -ls So this may have been solved already, the question is: Will this functionality be compiled in when there is no gdmflexiserver available at compile time? Usually, there will only be one login manager installed. How about changing the patch to use the following search order: LightDM->GDM->KDM?
The checks that "configure" does just set the default value of newLoginCommand in the .ad file, which is consulted at run-time. It can also be overridden by ~/.xscreensaver on a per-user basis.
Created attachment 295365 [details, diff] Add entry for LightDM gdmflexiserver to configure.in, revised search order Same as attachment 294547 [details, diff], but this additionally changes the search order to LightDM->GDM->KDM as proposed in comment #9.
Created attachment 295367 [details, diff] Patched xscreensaver-5.15.ebuild to make it apply the changes, with additional einfo. Thanks Jamie Zawinski, that clarifies things up. How about just placing an einfo in the ebuild (see patch) that tells the user how to enable the function when the use-flag is activated? Does that proposal, together with the patch, make everyone happy?
Comment on attachment 294549 [details, diff] Patched xscreensaver-5.15.ebuild to make it apply the changes. Obsoleted by attachment 295367 [details, diff].
should be all set in portage now
