org.freedesktop.PowerManagement

[Richard Hughes]

On Fri, 2007-03-30 at 09:25 -0400, Dan Winship wrote:
> Richard Hughes wrote:
> > On Thu, 2007-03-29 at 18:31 -0400, David Zeuthen wrote:
> >> Perhaps it's just easier to remove these from the org.fd.PM interface
> >> then and tell ISV's to do... something else. I don't know. What's the
> >> freedesktop.org story for this these days? How should an app reboot
> >> the system? XMSP? Wasn't Dan Winship of Novell working on this?
> 
> XSMP lets an app request a logout, but not a reboot/shutdown. In GNOME,
> reboots and shutdowns are really handled by gdm, so currently if you
> want to shutdown/reboot directly from the desktop (like the panel and
> gnome-power-manager do), you have to use a secret gdm protocol to tell
> gdm to reboot/shutdown after the current session, and then use XSMP to
> tell gnome-session to log out without presenting a dialog to the user
> (and then once gnome-session exits, gdm does what you told it to).
> 
> XSMP is not really extensible, so if we want something better than this,
> it would have to be via D-Bus anyway. I'd been thinking about eventually
> having a standard D-Bus interface for the session manager, with Logout,
> Reboot, and Shutdown commands. Putting those commands on a session
> management interface would solve the objection some people had that
> those commands should always be available even if you aren't running any
> sort of power manager.

Sure. That would be good. I'm quite prepared to either deprecate the
Shutdown and Restart methods, or just proxy them when GNOME and KDE both
have a common session abstraction, but that could be a long time coming;
No insult intended to anybody here.

> > Ick. So completely different ways to this. Doing this via XMSP also
> > breaks the InhibitManual semantics also, as then we have to inhibit the
> > session using XMSP (somehow) just to stop a shutdown half-way through a
> > partition resize. Complexity central.
> 
> Well, but in that case you'd want to inhibit *logout* as well as
> reboot/shutdown anyway, right? (Since logging out would kill X and
> probably the partition-resizing app along with it.) So the session
> manager needs to be involved somehow anyway. The easy way to do this
> would be to have the power manager (or the partition-resizing app
> itself) register as an XSMP client, and when it receives a logout
> notification, cancel the logout and pop up a dialog explaining why. (Or
> pop up an "are you sure blah blah blah" dialog and cancel or don't
> cancel the logout accordingly.)

That's the plan, although I admit I never quite understood the exact
subtleties of XSMP, hence why it's not in g-p-m yet.

> You're going to need the power manager to talk to the session manager
> anyway, because if the power manager is handling o.f.PM.Shutdown, it's
> probably going to want to implement it basically the same way g-p-m does
> now (letting the session manager deal with the logout part), so that the
> user gets logged out cleanly rather than just killing all his
> processes.

Yes, that fine as a long term plan, but I want something we can shove at
ISV's and application developers really soon.  I see *worst case* we
have to proxy the method when the session abstraction comes about.

Cheers,

Richard.