Re: [gpm] Common system interface for PowerManagement

[David Zeuthen <david fubar dk>]

On Thu, 2006-10-05 at 22:07 +0200, Holger Macht wrote:
> Of course it will. The application started on boot just grabs the
> interface with low priority (ALLOW_REPLACMENT). From a priority
> standpoint, both a KDE and a GNOME applet have the same high priority, so
> they will always grab the interface when they pass REPLACE_EXISTING.

Right.

> > Sounds good to me, I proposed something very similar right here
> > 
> >  http://bugzilla.gnome.org/show_bug.cgi?id=356174
> > 
> > with just using a wrapper in front of the daemon. If you're right about
> > no race when making the system bit release the interface when the
> > session bit requests it... then we probably don't need it.
> 
> Yes, that's something similar, although the PauseService() method you are
> proposing are not needed IMO. The low priority daemon can check whether it
> still possesses the interface, and if not, do nothing. It can just sleep
> and automatically (without any code) regrabs the interface when the higher
> priority app releases it.

Yep.

> > Btw, this is reusable for other policy daemons too (g-v-m, nm-applet and
> > KDE equivalents) without too many code changes except for supporting an
> > option "--headless". But my proposal is mostly just an implementation
> > detail. 
> > 
> > Would be good with a generic spec proposed on xdg-list fd o about this
> > that defines the names
> > 
> >  org.freedesktop.PolicyManager.Power
> >  org.freedesktop.PolicyManager.Network
> >  org.freedesktop.PolicyManager.Volume
> >  ...
> 
> Hm, I'm not sure if such a grab-regrag mechanism is actually enough for
> all cases. As soon as the system interface is grabbed by a higher level
> desktop application, the first started application consedes entirely all
> responsibilities to the desktop application, although it doesn't know yet
> if the desktop user actually possesses the required priviliege to care
> about that. And what happens if the desktop application isn't allowed or
> it is forbid by the admin to care about some tasks? What about the
> administrator forbidding users to control CPUFreq but allowing them to
> assign keys to actions such as shutdown? So this interface wouldn't be
> enough then. If the the user is not allowed to control CPUFreq, even
> though there has to be an application caring about this nevertheless. Hm,
> just thinking...

If the sysadmin denies policy daemons to certain things on behalf of
certain users then he better make sure that either 

 a) the system-wide instance of a policy daemon is doing what he wants
    even if a desktop-wide instance of a daemon is running; e.g.
    continue to run and only do a subset of the tasks it's doing
    when running normally... (e.g. when no-one is logged in). One could
    build this into the policy daemon code you have running system-wide
    e.g. powersaved would continue to do certain things even when g-p-m
    is running. Or system-wide g-p-m would do certain things even when
    klaptopd is running.

 b) that the system is already configured in a way he wants without
    having to run a daemon.

Realistically I think it's not going to cause problems - at the end of
the day all policy manager daemons should support the same feature set
anyway. Perhaps our spec could mention what minimum feature set a policy
daemon should implement in order to qualify to take the name?

There's also the case of fast user switching and multi-seat when you
have > 1 session on the box. Then it's not unrealistic that you have,
say, three instances of g-p-m and one instance of kpowersaved running in
the four sessions on the box. 

How we synchronize this is an interesting question. My thinking for this
includes 

 - making HAL deny calls if the session that is not active on a console
   (will fix fast-user switching; e.g. g-p-m on inactive session will
   not change the LCD backlight because the inactive session becomes
   idle.)

 - for suspend-when-idle have some way of having a session veto the
   request to suspend the machine. Will most likely include registering
   a veto handler somehow and having each veto-handler ACK or NAK the
   request.

Somewhat tricky but this might be solved soon. Either way, f-u-s and
multi-seat isn't relevant to this thread. I mean... because if you have
> 1 desktop sessions... then the 2nd policy manager daemon started will
just continue even if the 1st policy manager daemon holds the
org.freedesktop.PolicyManager.Power name. 

So if the 1st one exits the 2nd one will try to grab it again as soon as
possible. I think actually D-Bus allows you to queue owners of names so
the 2nd one will just sit in a queue behind the 1st one.

So two questions

 - what do you think of the ideas for handling f-u-s and multiseat?

 - do you agree we can go ahead and write the spec even though we don't
   have the infrastructure for f-u-s and multiseat? (cf. we just need
   to add the requirement that if the session daemon cannot obtain the
   Name it needs to queue up).

(Yes, f-u-s and multi-seat is a bitch to get right as it's insanely
complicated. But I think we're on the right track.)

> [Just a related note: What I had (and recently removed) in regard to
> kpowersave/powersaved was some kind of capability management. Kpowersave
> requested some capabilities from powersaved and powersaved told kpowersave
> for what it is allowed to care]
> 
> > 
> > (prefer to use the prefix PolicyManager otherwise we'll clash with
> > org.freedesktop.NetworkManager when implementing this for the networking
> > bits). I think it might be as easy as just pasting your original email
> > in and generalizing it a bit further.
> > 
> > On a different but related note. Said spec could also define the
> > interfaces that were proposed here
> > 
> >  http://lists.freedesktop.org/archives/xdg-list/2006-May/008139.html
> 
> Unfortunatelly the discussion following this post was not very
> productive. And rereading the proposed interfaces, I'm still doubt the
> need of them. But yes, this is a different discussion.

I'm pretty sure we need something like this. How else do you propose
that e.g. Totem, Realplayer and other movie players inhibit the screen
saver and the power manager (e.g. prevent the screen saver from kicking
in and prevent g-p-m from blanking the screen / dimming the LCD / etc.)?

But, yea, it's a different discussion.

    David