Please standardize Screen saver DBus interfaces
Brian J. Tarricone
bjt23 at cornell.edu
Fri May 15 13:43:08 PDT 2009
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
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
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.
More information about the xdg