Bug 928825 - disable screen blanking and system suspend/poweroff for Live images during installation
Summary: disable screen blanking and system suspend/poweroff for Live images during in...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: David Shea
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 965896 981461 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-28 14:15 UTC by Kamil Páral
Modified: 2015-06-02 13:56 UTC (History)
19 users (show)

Fixed In Version: anaconda-21.28-1
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-07 15:05:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Kamil Páral 2013-03-28 14:15:42 UTC
Description of problem:
Screen blanking (turning off the monitor) is generally a good idea on the installed system, but a bad idea during system installation. Some people are annoyed when they need to wait 40 minutes for the installer to finish, but have to wiggle the mouse every 5 minutes just to see the progress. Other users, mostly beginners but not limited to them, can be scared: "What just happened? Did something go wrong?". Also, if you decide to press some key to cancel the screensaver, you can never be fully sure it won't propagate to the foreground application. That makes you think like "If I hit Esc now to get rid of the screensaver, can I break something in the running installer?".

The screen blanking should be simply turned off during installation, there is no benefit - the possible few watts saving is negligible in a one-shot environment. But the "shock" or "annoyance" moment is quite real.

From what I can tell, most other spins also disable screensaver, either through default settings (KDE) or using a livesys patch (XFCE, LXDE, SoaS). It is also disabled in Anaconda DVD/netinst environment.

Please include the following patch to disable screen blanking in a GNOME Live environment. The installed system won't be affected, default GNOME settings won't be changed.

diff --git a/fedora-live-desktop.ks b/fedora-live-desktop.ks
index 5da81e2..0121020 100644
--- a/fedora-live-desktop.ks
+++ b/fedora-live-desktop.ks
@@ -30,6 +30,12 @@ cat >> /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.updates.gsc
 active=false
 FOE
 
+# disable screen blanking (it's scary to turn off monitor during system installation)
+cat >> /usr/share/glib-2.0/schemas/org.gnome.desktop.session.gschema.override << FOE
+[org.gnome.desktop.session]
+idle-delay=0
+FOE
+
 # make the installer show up
 if [ -f /usr/share/applications/liveinst.desktop ]; then
   # Show harddisk install in shell dash


Version-Release number of selected component (if applicable):
spin-kickstarts git b9ed586

Comment 1 Matthias Clasen 2013-03-28 17:12:50 UTC
The live installer should just inhibit the session from going idle. That will prevent screen blanking, locking or turning off.


You can do so using the freedesktop screensaver d-bus api (org.freedesktop.Screensaver.Inhibit) or using the xdg-screensaver wrapper

Comment 2 Bastien Nocera 2013-03-28 17:15:27 UTC
(In reply to comment #1)
> The live installer should just inhibit the session from going idle. That
> will prevent screen blanking, locking or turning off.
> 
> 
> You can do so using the freedesktop screensaver d-bus api
> (org.freedesktop.Screensaver.Inhibit)

Yes.

> or using the xdg-screensaver wrapper

Don't use that horror.

Comment 3 Kamil Páral 2013-03-29 09:27:34 UTC
Isn't that achieving exactly the same thing as setting idle-delay=0 ? Is there some another benefit in using the inhibitor? Because overriding gsettings schema is very easy, but calling dbus methods from the livesys script might not work really well (it's executed early in the system startup). Why not use the easy way?

If you insist on dbus approach being cleaner for some reason, can you please provide the relevant command? I'll gladly build the LiveCD and test it.

Comment 4 Kalev Lember 2013-04-07 15:49:40 UTC
(In reply to comment #3)
> /.../ calling dbus methods from the livesys script might not work really well
> (it's executed early in the system startup) /.../

Matthias and Bastien are suggesting that instead of doing it from the livesys init scripts, Anaconda (the live installer) itself should inhibit the screensaver.

Comment 5 Kamil Páral 2013-04-08 13:08:34 UTC
Thanks, Kalev, I have missed the "installer" word in Matthias' post. I agree, the installer should suppress the screensaver. It should also suppress system suspend/poweroff during the installation. All of that can be done now via systemd:

http://www.freedesktop.org/wiki/Software/systemd/inhibit

Reassigning to anaconda.

Comment 6 Chris Lumens 2013-04-10 19:17:42 UTC
We can do this, but I'm not willing to chase down a different method every release and every desktop.  What assurances do we have that the mechanism for disabling screen blanking will be at all stable?

Comment 7 Matthias Clasen 2013-04-10 22:51:41 UTC
The org.freedesktop.ScreenSaver[1] interface was invented solely to have a stable api for disabling screen blanking that doesn't have a capital g in its name, so I think there is some hope that it will be stable enough for your purposes.

[1] http://people.freedesktop.org/~hadess/idle-inhibition-spec/index.html

Comment 8 Ira Malinich 2013-04-18 22:39:20 UTC
Is there a reasonably stable way to disable/inhibit screen blanking only while using AC power?  I think the battery scenario may still be a valid case for turning off the display during install.  Opinions?

Comment 9 Kamil Páral 2013-04-19 08:58:14 UTC
(In reply to comment #8)
I don't think that we should add more complexity here. Then you would also need to handle changes in AC/battery power during the installation, and that's not really worth it. My opinion.

However, installer should definitely warn a user if he tries to perform an installation without AC power. That issue should be filed separately. Please feel free to create a new ticket about it (after you verify that anaconda doesn't do that already). Thanks.

Comment 10 Chris Lumens 2013-04-23 17:54:40 UTC
I've got code ready to roll on this, it looks like the live image is missing whatever provides the service.  Reassigning there, but feel free to reassign back to me once the pieces are in place.

Comment 11 Kamil Páral 2013-04-24 08:53:17 UTC
Chris, I've booted F19 Alpha Live x86_64, installed d-feet, and I see org.freedesktop.ScreenSaver object path present in the session bus. Maybe you've been looking at the system bus?

Comment 12 Kamil Páral 2014-03-17 14:02:55 UTC
Moving back to anaconda for assessment. Also it might be interesting to look at the systemd inhibit API, that could also be sufficiently cross-platform nowadays.

Comment 13 David Shea 2014-03-17 18:34:35 UTC
`systemd-inhibit --what=idle anaconda ...' just failed to do anything on the GNOME live image, so apparently this is not yet ready for anaconda.

Comment 14 Kamil Páral 2014-03-18 09:50:21 UTC
Instead of assigning back to spin-kickstarts and waiting another year for nothing to happen, let's try to fix this. I've tried this on my installed F20:

$ systemd-inhibit --what idle gedit

and I see the lock in `systemd-inhibit --list`, but screen locking&blanking still occurs. So either we're using it wrong, or it doesn't work, and the problem is either in systemd or gnome. I have reported bug 1077579 and make it block this bug.

rtcm_ on #fedora-desktop told me that gnome might not use logind for idle detection. If we can confirm that, then the issue is clear.


I have also tried org.freedesktop.ScreenSaver DBUS interface using D-Feet in F20 Live. It seems to be working perfectly. I was able to inhibit the screensaver and uninhibit it again.

So anaconda has two choices:
1) wait until systemd-inhibit issue is resolved and if it turns out to be a problem in systemd (and gnome turns out to actually support it), implement it once it is fixed
2) just use the org.freedesktop.ScreenSaver API. That can be done right now. The only minor disadvantage is that you need to release the lock manually once anaconda quits, it's not done automatically as with systemd lock, IIUIC.

Reassigning back. This issue doesn't seem to be related to spin-kickstarts, at least according to my testing. If the org.freedesktop.ScreenSaver API doesn't work for you, please include some details.

Comment 15 Kamil Páral 2014-03-18 10:00:55 UTC
Bastien Nocera confirmed that systemd-based idle inhibiting is not supported in GNOME, and it's not in any immediate plans either. Therefore anaconda should probably use the freedesktop DBUS API.

Comment 16 Chris Lumens 2014-03-18 14:22:20 UTC
*** Bug 965896 has been marked as a duplicate of this bug. ***

Comment 17 David Shea 2014-03-18 15:10:15 UTC
(In reply to Kamil Páral from comment #14)
> Instead of assigning back to spin-kickstarts and waiting another year for
> nothing to happen, let's try to fix this. I've tried this on my installed
> F20:

To fix this we need something that actually works, and that means that the spins have to provide something that works across all of the spins.

I tried using the following command as liveuser:

dbus-send --session --dest=org.freedesktop.ScreenSaver --type=method_call --print-reply --reply-timeout=-1 /org/freedesktop/ScreenSaver org.freedesktop.ScreenSaver.Inhibit string:'anaconda' string:'Installing'

In GNOME this returned an inhibit ID, and it still went idle and activated the screensaver. In KDE I got:

org.freedesktop.ScreenSaver.Inhibit string:anaconda string:Installing
Error org.freedesktop.DBus.Error.UnknownObject: No such object path '/org/freedesktop/ScreenSaver'

So back in comment 10, when Chris said:

> I've got code ready to roll on this, it looks like the live image is missing whatever provides the service.

That's still the case.

Comment 18 David Shea 2014-03-18 15:12:20 UTC
(In reply to David Shea from comment #17)
> Error org.freedesktop.DBus.Error.UnknownObject: No such object path
> '/org/freedesktop/ScreenSaver'

Accidentally copied part of the command again. The Error line is all that came back from dbus-send, indicating that KDE is not implementing this session interface.

Comment 19 Kamil Páral 2014-03-18 17:12:54 UTC
I asked Bastien on #fedora-desktop:

<kparal> hadess: could you please have a look at https://bugzilla.redhat.com/show_bug.cgi?id=928825#c17 and help David discover why he's unable to inhibit GNOME session using org.freedesktop.ScreenSaver?
<kparal> it worked for me when using d-feet, but I'm not really used to use dbus-send. maybe there's some error in the command line?
<hadess> you can't do that on the command-line, as soon as the call ends, it will stop the inhibition
<hadess> kparal, and in KDE, they have a broken implementation
<hadess> kparal, use "/" as the object path
<kparal> for KDE?
<hadess> kparal, yeah
<kparal> anaconda guys won't be happy
<hadess> kparal, not my fault kde sucks...
<kparal> sure
<kparal> thanks for help
<hadess> kparal, get one of the kde developers to actually fix their implementation

So, that's the reason why it "worked" for me - I used d-feet and didn't quit the application, therefore the idle lock was active. If you call this from the liveinst/anaconda process instead, the lock should be active as well, until the process ends (you don't even need to uninhibit, nice).

For KDE, the call needs to be a bit different. But I'm not convinced you need to deal with it in the first place. Because
a) if some DE doesn't implement the spec properly, it's not your problem and they should fix - I can report the bug.
b) KDE Live image doesn't seem to perform any screen blanking at all by default. So there's no problem at all. (As even comment 0 said).

Is there something else I should help you with, or can you implement it now? If the dbus call fails, just print a warning into your log, and carry on. This should fix the screen blanking for GNOME (and any other DE implementing the spec properly) and make no difference for KDE (where there's no blanking anyway).

Comment 20 David Shea 2014-03-18 17:20:28 UTC
Thanks for tracking the info down.

Comment 21 David Shea 2015-06-02 13:56:05 UTC
*** Bug 981461 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.