Tuesday 14 June 2011

Disabling screensaver/lock-screen on Gnome 3 during Flash movies

With the release of Gnome 3, most of the old Gnome APIs have undergone major changes. Many of these changes are not backward compatible at all. This presents an interesting challenge; specially at this still early stages of Gnome 3 developement - where almost everything is in a state of flux.

I regularly watch tech presentations from conferences - which are usually presented as Flash videos. Annoyingly, this means that the screen-lock will kick-in every few minutes and blank out the screen if I forget to move the mouse around.  Caffeine was the perfect answer for this situation before, but unfortunately due to API differences, it was no longer working on Gnome 3.  Setting the lock-screen activation delay to its' max value (1 hour - if using the GUI) was not an acceptable solution because I want the screen to blank out and lock itself quite quickly if I am away from the computer for a while.

My investigation into the Gnome lock-screen internals first led me to the following two dconf settings that are related to idle activation:

  • org.gnome.desktop.session.idle-delay - Number of seconds of idle activity before the screen is locked.

  • org.gnome.desktop.screensaver.idle-activation-enabled - Set whether idle detection is enabled.


Existing values for these can be obtained by running the commands:
gsettings get org.gnome.desktop.session idle-delay
gsettings get org.gnome.desktop.screensaver idle-activation-enabled

Values can be changed by using the following commands:
gsettings set org.gnome.desktop.session idle-delay 1800 
gsettings set org.gnome.desktop.screensaver idle-activation-enabled false

On my first attempt, I wrote a Python script that detects when Flash is active and sets the above settings to control the screen-lock activation. However, changes made to GSettings don't seem to propagate back to the relevant components in a timely manner. So the behaviour was mostly unpredictable. It also didn't feel like a very elegant solution to my problem either.

Going back to the drawing boards, I spent a few nights hunting for documentation about Gnome ScreenSaver and SessionManager. It should be mentioned that the one thing that Gnome 3 lacks the most is documentation. I finally ended up reading the Totem media player source code to figure out how it was disabling the screensaver during media playback. It turns out that in Gnome 3, the DBus interface for inhibiting the screensaver had moved from org.gnome.ScreenSaver interface to the org.gnome.SessionManager interface. The method signature has also changed. It now requires an application_id (Gnome specific identifier for applications that are currently running) and the toplevel XID (X Windows handle) of the application in addition to the inhibit reason and the flags. Some nice documentation on this can be found at http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit.

This revelation about the DBus solution led to further questions:
Q) How can I check the DBus interface on the actual system to make sure it hasn't changed since it was documented above?
A) D-Feet to the rescue. It's a very handy utility for exploring the active DBus interfaces on the system. I couldn't get it to work off the installation - possibly due to some path problem. However, I could get it to work off of the local directory by running:
d-feet -l

Q) How do I get an application_id and XID to pass to the DBus method call ?
A) I spent quite a lot of time poring through GTK documentation to figure this out - but couldn't find an easy solution. What I did find from my experiments is that these parameters are not really required for the method call to work. You can pass any string value as the app_id and any integer value as the XID and the call will still work correctly. It's an ugly hack, but as they say, perfect is the enemy of good :)

Q) How can I quickly check that the DBus method calls work?
A) I first used dbus-send as follows:
dbus-send --session --dest=org.gnome.SessionManager --type=method_call --print-reply --reply-timeout=20000 /org/gnome/SessionManager org.gnome.SessionManager.Inhibit string:"myApp" uint32:0 string:"Inhibiting" uint32:8

To see if the method call worked, I used the IsInhibited method.
dbus-send --session --dest=org.gnome.SessionManager --type=method_call --print-reply --reply-timeout=20000 /org/gnome/SessionManager org.gnome.SessionManager.IsInhibited uint32:8

The biggest gotcha here is that IsInhibited will always return false. This is because the Gnome Session Manager automatically removes the inhibition if the process calling Inhibit dies. Since Inhibit was called from the dbus-send process which immediately terminates, the inhibition is already removed by the time IsInhibited is called. I spent several hours cursing and losing tufts of hair to figure that one out.
The solution is to use something like iPython. I opened a new console window, started iPython and typed the following commands in it:
import dbus
bus = dbus.SessionBus()
proxy = bus.get_object('org.gnome.SessionManager','/org/gnome/SessionManager')
proxy.Inhibit("something",dbus.UInt32(0),"inhibiting",dbus.UInt32(8))

Then I used dbus-send to call IsInhibited from a different console window and voila!

And this finally leads us to the end. Rather than reinventing the wheel, I decided to contribute the outcome of my research back to the excellent Caffeine application. My branch of Caffeine in LaunchPad now has full support for inhibiting the screensaver in Gnome 3. Hopefully the lead developers will accept my changes back into the trunk and it will soon be widely available to everybody else.

Edit: My changes have been accepted and merged back in to the Caffeine trunk. http://bazaar.launchpad.net/~caffeine-developers/caffeine/main/revision/377

4 comments:

safetytrick said...

thank you, this rocks

emdoubleyou said...

Quick inhibit applet

http://www.michaelwood.me.uk/wordpress/2011/09/16/inhibit/

CL0NE said...

Useful gnome3 extension - Inhibit applet

Alexander said...

Thank you very much for this article!