Please standardize Screen saver DBus interfaces

[Brian J. Tarricone]

Patryk Zawadzki wrote:
> On Fri, May 15, 2009 at 9:59 AM, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
>> Further... you *don't* want a media player (etc.) calling Inhibit on the
>> power manager.  You want to tell the screen saver to stay out of the way
>> for a while, but if the machine (for example) is critically low on
>> battery, you probably still want it to go into sleep or hibernate mode
>> to save your current state.
> 
> That's not what I meant at all. What I said is that ideally the power
> manager should expose a way to disable powering down a certain screen,
> not inhibit the shutdown/hibernation. Notice I mean a certain screen,
> not all screens. There are setups when one of the monitors is used to
> display real time calculations or statistics while the rest can be
> safely turned off when session is idle. The power manager would
> internally use the information to grab necessary inhibits on the
> currently running screensaver interface.

I don't really see this as the power manager's job.  It's the screen 
saver's.

 From another angle: this should be possible on window managers and 
desktop environments that don't have a power manager.  I don't see why 
the power manager should be handling screen saver inhibit; the screen 
saver should support it on its own.  A media player that wants to 
inhibit the screen saver under the "power manager handles it" scheme has 
to depend on two things: 1) a power manager existing and knowing how to 
control the particular screen saver, and 2) a supported screen saver 
existing and running.  At least with pushing this to the screen saver 
you're only depending on the screen saver being un-lame.  The fallback 
code that does something like use XTest to fake a keypress when the X 
idle timer goes above 30 seconds will probably have to remain 
forevermore regardless... so pushing this into the power manager really 
serves no benefit.

> I don't see how we can achieve interoperability with inhibiting the
> screensaver directly as there are screensavers that don't support DBus
> at all and I believe it's easier to keep the necessary hacks in one
> place rather than teach each and every application how to inhibit all
> of the possible screensavers :)

As long as a screen saver supports *some* means of remote control from 
the command line, it's trivial to implement a dbus service that wraps 
things like 'xscreensaver-command -deactivate' for example.

Pushing the logic into the power manager just means that the power 
manager has to be aware of all the different screen savers and how to 
inhibit each one.

As more desktops care about power management, this number grows... 
perhaps not as quickly as the number of video players, but it still 
grows.  There should be ONE blessed way of inhibiting ANY screen saver. 
  The logical choice seems to be an org.freedesktop.ScreenSaver 
interface.  Screen savers that don't support it can:

1) get that support added,

2) get wrapped by a python script (or whatever; I hate python) that 
emulates the service by shelling out to the screensaver's remote control, or

3) just not be used by people who care about this working properly.

While the Linux way of "many different ways of doing things" can be 
great sometimes, in this case it's a huge detriment to Things Not 
Sucking[tm].

	-brian

P.S. I'm reminded of a semi-recent blog post from Dan Williams about the 
need for chipset specific workarounds in NetworkManager.  In the end, he 
got fed up with all the variation and fixed the drivers to behave the 
same.  Screen savers should behave the same too.