Description of problem: I see xscreensaver references in two autostart config files. Are they conflicting ? $ cat /etc/xdg/lxsession/LXDE/autostart @lxpanel --profile LXDE @pcmanfm --desktop --profile LXDE @xscreensaver -no-splash @pulseaudio -D $ ls /etc/xdg/autostart/ gnome-keyring-gpg.desktop nm-applet.desktop gnome-keyring-pkcs11.desktop parcellite-startup.desktop gnome-keyring-secrets.desktop print-applet.desktop gnome-keyring-ssh.desktop sealertauto.desktop gsettings-data-convert.desktop user-dirs-update-gtk.desktop imsettings-start.desktop xscreensaver-autostart.desktop lxpolkit.desktop There could be in here as well (as in /etc/xdg/autostart/; not now): $ ls -l .config/autostart total 0 Version-Release number of selected component (if applicable): lxsession.i686 0.4.5-3.fc15 @koji-override-0/$releasever How reproducible: n/a Steps to Reproduce: 1. n/a 2. 3. Actual results: n/a Expected results: n/a Additional info:
They are kind of conflicting: /etc/xdg/autostart/xscreensaver-autostart.desktop launches /usr/libexec/xscreensaver-autostart. $ cat /usr/libexec/xscreensaver-autostart #!/bin/sh # Don't launch xscreensaver if gnome-screensaver # is installed if [ -x /usr/bin/gnome-screensaver ] ; then exit 0 ; fi exec xscreensaver -nosplash As soon as /usr/bin/gnome-screensaver is present, xscreensaver is not started. The only way to make really sure is to have the second file. I need to think about this, maybe I will remove it from /etc/xdg/lxsession/LXDE/autostart.
(In reply to comment #1) > I need to think about this, maybe I will remove it from > /etc/xdg/lxsession/LXDE/autostart. That's what I think too. The user does not know about /etc/xdg/lxsession/LXDE/autostart, which starts: $ ps aux |grep -i xscreen jb 1609 0.0 0.2 5552 2068 ? S 08:46 0:02 xscreensaver -no-splash But the user knows how to control autostart apps thru: Preferences - Desktop Session Settings which corresponds to files in dir /etc/xdg/autostart/, and which is the right thing to do. If the user does that, then there would be a conflict with the above. JB
Created attachment 505582 [details] conflicting autostart config - recommended solutions This is a continuation of the analysis and recommended solutions. Note that this will apparently fix other errors/issues as well. JB
Thanks for the analysis. - pulseaudio: I will investigate this, but as mentioned already, I cannot reproduce your problem. I wonder what starts pulseaudio if not /etc/xdg/lxsession/LXDE/autostart. - pcmanfm: Is a core component of LXDE, it is required to show the desktop and to handle removable devices. It must be running all the time in daemon mode and if it crashes, it must be restarted. This is only possible through /etc/xdg/lxsession/LXDE/autostart but not in /etc/xdg/autostart/. I am not going to make this one configurable because Fedora's LXDE would then be different from upstream's LXDE. This would need documentation and still lead to a high number of bugs - and I am the one to receive all the bug reports. - xscreensaver: What about users who have installed both GNOME and LXDE? They will not be able to enable a screensaver, neither xscreensaver nor gnome-screensaver will work. This makes problems like bug 614608 worse.
(In reply to comment #4) > Thanks for the analysis. > > - pulseaudio: I will investigate this, but as mentioned already, I cannot > reproduce your problem. I wonder what starts pulseaudio if not > /etc/xdg/lxsession/LXDE/autostart. I would assume the lxpanel. The Pulseaudio Volume Control is an lxpanel element (added thru Add/Remove Panel Items), and so pulseaudio daemon may be a prerequisite. > > - pcmanfm: Is a core component of LXDE, it is required to show the desktop and > to handle removable devices. It must be running all the time in daemon mode and > if it crashes, it must be restarted. This is only possible through > /etc/xdg/lxsession/LXDE/autostart but not in /etc/xdg/autostart/. > I am not going to make this one configurable because Fedora's LXDE would then > be different from upstream's LXDE. This would need documentation and still lead > to a high number of bugs - and I am the one to receive all the bug reports. Yes, pcmanfm is part of LXDE, but perhaps not as essential as e.g. lxpanel to be required to run at all times. Do not panic - if you, and LXDE, and pcmanfm maintainer will agree with arguments below, you may become a hero :-) Now, I do not have pcmanfm running: $ cat /etc/xdg/lxsession/LXDE/autostart @lxpanel --profile LXDE The automount/autofs is not installed. $ yum list "*autofs*" Available Packages autofs.i686 1:5.0.5-35.fc15 fedora Note: hal is retired (somehow still here). # ps aux |grep -i hald ... root 3612 0.0 0.1 4124 832 ? S 16:53 0:00 hald-addon-storage: polling /dev/sr0 (every 2 sec) Note: the new kid in town is udisks, which provides a system message bus, and relies on udev and kernel - udisks(7). # ps aux |grep -i udisks root 1234 0.0 0.3 23920 2988 ? Sl Jun19 0:14 /usr/libexec/udisks-daemon root 1237 0.0 0.0 6236 272 ? S Jun19 0:12 udisks-daemon: polling /dev/sr0 I start pcmanfm to have it "ready" in background. $ pcmanfm --desktop --profile LXDE & [1] 3633 $ ps aux |grep -i pcman jb 3633 7.3 1.1 97112 8364 pts/1 S 16:54 0:00 pcmanfm --desktop --profile LXDE ===========> my activities - inserted cd-rom ===========> my activities ** (pcmanfm:3633): DEBUG: try automount ** (pcmanfm:3633): DEBUG: on_mount_action_finished So, it seems that only with automount present and configured, a running pcmanfm would be let know of new media (hd, usb, cd, etc) and perhaps pop up on the desktop ? But, in order to have this functionality, you do *not* need pcmanfm running as a daemon in the background at all times ! The system is plugin-events sensitive (hal, udisks, udev, inotify), there are also system buses like e.g. dbus and udisks available, and events like these should be recognized by the system dynamically, and desktop should be configurable to call (or not) pcmanfm as needed. This should also work if you started pcmanfm ad hoc manually. I think the pcmanfm maintainer would be more than happy to provide this capability (the infrastrucuture is already there); it may be already partially implemented and available. If you look at: http://wiki.lxde.org/en/PCManFM_build_and_setup_guide you see that it is already capable of: Setup Runtime Environment Correctly Runtime Dependencies ... gvfs and its dependencies (optional, but highly recommended) dbus and dbus-glib (required by gvfs) policykit-gnome (required for authentication for volume management) ... There is no need to run pcmanfm constantly in the background and waste system resources (we already have so many more or less "useless" daemons). I noticed LXDE is lean and fast, and it should be kept that way - it is a matter of a good design. A candidate for LXDE request-for-enhancement ? > > - xscreensaver: What about users who have installed both GNOME and LXDE? They > will not be able to enable a screensaver, neither xscreensaver nor > gnome-screensaver will work. This makes problems like bug 614608 worse. Firstly, you should be concerned about LXDE working properly - it has a lot of potential if improved, in particular if you consider that the alternatives are slow, bloated, and suck inmany ways possible. Secondly, if they decide for both (GNOME, LXDE) then let them decide which screensavers they want to run by configuring the DEs appropriately - see your comment #1 - you will find a way to do it. JB
> ... > > - xscreensaver: > > ... > > This makes problems like bug 614608 worse. > The user is in control of her machine and its configuration ! The way it should work is this: - no xscreensaver in /etc/xdg/lxsession/LXDE/autostart - Preferences - Desktolp Session Settings governs behaviour xscrensaver-autostart control checked off - xscreensaver disabled xscrensaver-autostart control checked on - xscreensaver started in background and behaving according to its configuration in Preferences - Screensaver - Blank After - Lock Screen After - I have it configured with Lock Screen After checked on, and every time I return from Suspend and Lock Screen After time was past due, the xscreensaver greets me with a login dialog. So, it works as the user configured it. And users should be told so every time they complain. JB
(In reply to comment #6) > > ... > > > - xscreensaver: > > > ... > > > This makes problems like bug 614608 worse. > > > > The user is in control of her machine and its configuration ! > > The way it should work is this: > - no xscreensaver in /etc/xdg/lxsession/LXDE/autostart > - Preferences - Desktolp Session Settings governs behaviour > xscrensaver-autostart control checked off - xscreensaver disabled > xscrensaver-autostart control checked on - xscreensaver started in > background But this does not work as soon as gnome-screensaver is installed. xscreensaver will not be started even if you enable it in Desktop Session Settings. > and behaving according to its configuration in > Preferences - Screensaver - Blank After - Lock Screen After It's behaving according to the configuration anyway, regardless how it is started. > - I have it configured with Lock Screen After checked on, and every time > I return from Suspend and Lock Screen After time was past due, > the xscreensaver greets me with a login dialog. But the people who filed that bug expect that the screen should be locked *every* time you wake up from suspend, even if time is not yet up.
(In reply to comment #7) > (In reply to comment #6) > > > ... > > - I have it configured with Lock Screen After checked on, and every time > > I return from Suspend and Lock Screen After time was past due, > > the xscreensaver greets me with a login dialog. > > But the people who filed that bug expect that the screen should be locked > *every* time you wake up from suspend, even if time is not yet up. Then, functionally, it is linked to suspend process. Is there any way to "attach" xsreensaver to it ? Perhaps take a look at: /var/log/pm-suspend.log and there is e.g. /usr/lib/pm-utils/sleep.d/00powersave How about making xscreensaver part of its execution (on suspend and resume) ? JB
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > > ... > > > - I have it configured with Lock Screen After checked on, and every time > > > I return from Suspend and Lock Screen After time was past due, > > > the xscreensaver greets me with a login dialog. > > > > But the people who filed that bug expect that the screen should be locked > > *every* time you wake up from suspend, even if time is not yet up. > > Then, functionally, it is linked to suspend process. Is there any way to > "attach" xsreensaver to it ? > Perhaps take a look at: > /var/log/pm-suspend.log > and there is e.g. > /usr/lib/pm-utils/sleep.d/00powersave > How about making xscreensaver part of its execution (on suspend and resume) ? > JB The above is a possible solution. BUT, I do not think that this should be a permanent feature of LXDE experience. I agree with your opinions there that this is about *customization* : https://bugzilla.redhat.com/show_bug.cgi?id=614608#c5 https://bugzilla.redhat.com/show_bug.cgi?id=614608#c13 So, if the above would work, then you can suggest it to SUSE bug filer https://bugzilla.redhat.com/show_bug.cgi?id=614608 how they can accomplish that if they wish to customize to achieve their effect. You may want to place it in LXDE wiki as a customization tip for everybody as well. JB
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping