Re: [gpm] Common system interface for PowerManagement

[Holger Macht <hmacht suse de>]

On Thu 05. Oct - 17:04:38, David Zeuthen wrote:
[...]
> > > 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.

Yes, powersaved will do it this way because he still does things that
should not be or are not in HAL and which don't require user
interaction/configuration. But these are things which don't bother the
desktop user like hard disk settings, etc.

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

But what does a administration actually do when he for instance doesn't
want users to change the CPUFreq policy. He denies the privilege
hal-power-cpufreq from /etc/PolicyKit/privilege.d/hal-power-cpufreq for
all users. The system daemon can't know that the desktop application
taking over the common interface is actually not allowed to care about
CPUFreq. And you still want to care about because you might want to adjust
it on specific events, for instance battery removal.

> 
> 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?

Yes, this is a good idea. So one doensn't have to mess with our socalled
'capabilities'. We had that because we didn't imply that all
PolicyManagers have the same set of features. But that's a constraint we
should make.

> 
> 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.)

In case of LCD backlight, agreed. But you have to specify which methods
are f-u-s relevant.

I think of a session starting up, grabbing the system interface and thus
caring about CPUFreq. Later on, this session might currently not be active
but this session still has to care about CPUFreq.

> 
>  - 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.

Doesn't this require an interface on the system bus all sessions have
access to?

> 
> 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.

Right, I tried that and it worked.

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

See above.

>  - 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, I think that should be enough for now. That's what I've planned in
the beginning, first comes, first serves.

> (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.)?

I thought about the power manager interface in the first place and just
again looked over the initial post, should have mentioned that. Yes, I
also think we need something like this, but I don't agree on all methods
proposed ;-)

> But, yea, it's a different discussion.

Agreed :-)))

Regards,
	Holger