GNOME Bugzilla – Bug 339809
When downloading a large file, my laptop auto-suspended
Last modified: 2015-07-24 16:13:39 UTC
I'm the developer of gnome-power-manager. Stuff like nautilus can (and will) tell g-p-m that it's doing something in the background, and shouldn't auto-suspend. All Epiphany has to do is call a simple dbus method when a download starts, and a simple dbus method when it's finished. This way g-p-m doesn't auto-suspend or power-down. See http://live.gnome.org/GnomePowerManager/Faq and look at the "How do I make my application stop the computer auto-suspending?" section. If you have any questions/concerns then feel free to email me, or just close this WONTFIX :-) Thanks. Richard.
I have been wondering how to do this for a while .... thanks for the info, I will try and do this when I am back online at home. Does g-p-m 2.14 support this or do we need CVS to test ? CVS g-p-m is a bit of a problem for me as dapper doesn't have the appropriate version of dbus :-(
(In reply to comment #1) > I have been wondering how to do this for a while .... thanks for the info, I > will try and do this when I am back online at home. Cool, thanks. > Does g-p-m 2.14 support this or do we need CVS to test ? CVS g-p-m is a bit of > a problem for me as dapper doesn't have the appropriate version of dbus :-( Just CVS I'm afraid, as it needed large arcitectural changes. I can lower the DBUS dep on CVS (adding back the compat-code) if that makes things easier. Richard.
If it isn't too much of a pain, adding the compat-code back to CVS would be very useful to people wanting to try g-p-m CVS on dapper (like me), I had to stop using CVS g-p-m when the compat code went :-(
Can you try now please :-) 2006-04-26 Richard Hughes <richard@hughsie.com> * src/gpm-hal-monitor.c: (watch_device_connect_property_modified): * configure.in: Depend on a lower version of DBUS, as I've upset crispin and I need his help. #339809. Thanks, Richard.
You'll want to use Inhibit() and UnInhibit(). See http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/docs/gnome-power-manager.html#pm-Compatibility This is due to XDG standardisation.
Mass changing target 2.16 -> 2.18
For quick reference: #!/usr/bin/python import dbus import time bus = dbus.Bus(dbus.Bus.TYPE_SESSION) devobj = bus.get_object('org.gnome.PowerManager', '/org/gnome/PowerManager') dev = dbus.Interface(devobj, "org.gnome.PowerManager") cookie = dev.Inhibit('Nautilus', 'Copying files') time.sleep(100) dev.UnInhibit(cookie)
We need to get rid of bugs like #326608, #319500 and #327121 since they can make suspend capabilities useless. Marking #326608 as a dependency (the other two are related but doesn't seem directly blocking this). Also marking with mathusalem keyword since it will handle all of this in case it's ready before we fix #326608.
Moving to 2.20 target due to feature and UI freeze for 2.18.
*** Bug 534955 has been marked as a duplicate of this bug. ***
I think the current Gnome infrastructure supports everything we need here, right?
Ephy is a GtkApplication, so this should be as easy as: app = g_application_get_default(); cookie = gtk_application_inhibit (app, window, GTK_APPLICATION_INHIBIT_SUSPEND, "Downloading"); Should this be in the ephy-download object, or the download widget?
(In reply to comment #12) > Ephy is a GtkApplication, so this should be as easy as: > app = g_application_get_default(); > cookie = gtk_application_inhibit (app, window, GTK_APPLICATION_INHIBIT_SUSPEND, > "Downloading"); > > Should this be in the ephy-download object, or the download widget? Probably in the object, so that each object handles its cookie?
Created attachment 307623 [details] [review] Inhibit logout and suspend while downloading files Speculative patch, I haven't tested it yet because my debug build of WebKit master crashes whenever I download a file; I need to look into that....
Review of attachment 307623 [details] [review]: Inhibitor is never released; not yet sure why.
Created attachment 307912 [details] [review] Inhibit logout and suspend while downloading files I missed a spot where I needed to uninhibit. This patch works. To test set org.gnome.settings-daemon.power sleep-inactive-ac-timeout or sleep-inactive-battery-timeout to something small like 10 (seconds).
Review of attachment 307912 [details] [review]: ::: embed/ephy-download.c @@ +525,3 @@ + shell = ephy_embed_shell_get_default (); + + gtk_application_uninhibit (GTK_APPLICATION (shell), priv->inhibitor_cookie); This could be called with a 0 cookie, I would return early in case the cookie is 0. that would also allow us to call this on dispose without having to check the cookie. @@ +542,3 @@ webkit_download_cancel (download->priv->download); + + release_session_inhibitor (download); I don't think this is correct, the inhibitor will be released with a 0 cookie. You release the inhibitor here, the download is cancelled and then failed signal is emitted with CACELLED_BY_USER error and the inhibitor is released again in the failed callback. So, the release in the failed callback should be enough. That's why I think it's better to allow the acquire/release methods to be called multiple times. @@ +800,3 @@ download->priv->widget = NULL; + + download->priv->inhibitor_cookie = 0; This is already 0, glib fills with 0 the instance structs on allocation. @@ +858,3 @@ g_signal_emit_by_name (download, "error", 0, error->code, error->message, &ret); + + release_session_inhibitor (download); I think we should also release the inhibitor on dispose, in case the download object is destroyed in the middle of a download. Maybe we should also cancel a download on dispose if it's still running.
(In reply to Carlos Garcia Campos from comment #17) > This could be called with a 0 cookie, I would return early in case the > cookie is 0. that would also allow us to call this on dispose without having > to check the cookie. OK > I don't think this is correct, the inhibitor will be released with a 0 > cookie. You release the inhibitor here, the download is cancelled and then > failed signal is emitted with CACELLED_BY_USER error and the inhibitor is > released again in the failed callback. So, the release in the failed > callback should be enough. That's why I think it's better to allow the > acquire/release methods to be called multiple times. OK, good catch. > @@ +800,3 @@ > download->priv->widget = NULL; > + > + download->priv->inhibitor_cookie = 0; > > This is already 0, glib fills with 0 the instance structs on allocation. Good to know. I will remove it, although that function already initializes various widgets to NULL unnecessarily. > @@ +858,3 @@ > g_signal_emit_by_name (download, "error", 0, error->code, error->message, > &ret); > + > + release_session_inhibitor (download); > > I think we should also release the inhibitor on dispose, in case the > download object is destroyed in the middle of a download. Maybe we should > also cancel a download on dispose if it's still running. I will add another commit for this.
Created attachment 308001 [details] [review] Inhibit logout and suspend while downloading files
Created attachment 308002 [details] [review] EphyDownload: cancel download in dispose As suggested by Carlos, just in case the download object is destroyed in the middle of a download.
Review of attachment 308001 [details] [review]: Please, see my comment before pushing ::: embed/ephy-download.c @@ +547,3 @@ webkit_download_cancel (download->priv->download); + + release_session_inhibitor (download); As I said , this is no the right place, after a cancellation, failed_cb is called. Move this one to the dispose method.
Review of attachment 308002 [details] [review]: I wonder if we should check somehow if the download is still ongoing in cancel to return early. WebKit doesn't check that, I don't know what happens if a finished download is cancelled.
(In reply to Carlos Garcia Campos from comment #21) > ::: embed/ephy-download.c > @@ +547,3 @@ > webkit_download_cancel (download->priv->download); > + > + release_session_inhibitor (download); > > As I said , this is no the right place, after a cancellation, failed_cb is > called. No, failed_cb() is not called, because EphyDownloadWidget destroys itself after calling ephy_download_cancel() in cancel_activate_cb(), and I guess removes the last reference to the EphyDownload in ephy_download_widget_dispose(). But releasing it in dispose as well would take care of that case, so your suggestion is still good. (In reply to Michael Catanzaro from comment #20) > Created attachment 308002 [details] [review] [review] > EphyDownload: cancel download in dispose > > As suggested by Carlos, just in case the download object is destroyed in > the middle of a download. We don't need to do this; Download::platformInvalidate() handles cleaning up the download properly when the download object is destroyed. As it should; applications shouldn't have to bother with this. So instead I will just release the inhibitor explicitly in dispose, instead of relying on ephy_download_cancel() to do this.
(In reply to Carlos Garcia Campos from comment #22) > Review of attachment 308002 [details] [review] [review]: > > I wonder if we should check somehow if the download is still ongoing in > cancel to return early. WebKit doesn't check that, I don't know what happens > if a finished download is cancelled. Nothing happens if a finished download is cancelled, because m_resourceHandle will be null in Download::cancel in DownloadSoup.cpp. I'd say that's the expected behavior.
The following fix has been pushed: f8739c4 Inhibit logout and suspend while downloading files
Created attachment 308090 [details] [review] Inhibit logout and suspend while downloading files