org.freedesktop.PowerManagement

[Richard Hughes]

On Tue, 2007-03-27 at 12:28 +0200, Danny Kukawka wrote:
> On Dienstag, 27. März 2007, Richard Hughes wrote:
> > On Tue, 2007-03-27 at 09:02 +0200, Oswald Buddenhagen wrote:
> > > reboot. restart is ambiguous.
> >
> > Restart seems easier to understand to me, although I don't think it
> > matters that much.
> 
> This is the same as we discussed in HAL: we don't need fancy names here. These 
> interfaces are for delevoper and not for the user. In a normal case the user 
> should never see these interfaces. At least restart say nothing. Do this mean 
> restart the interface/the application which the interface provide or restart 
> the system? Reboot is non-ambiguous.

Yes, I think I agree with you. Reboot it is.

> > I think we should drop the GetBacklightBrightness stuff for now, and
> > punt that to another interface - one of the blog comments provides more
> > details about how it needs some more thinking.
> 
> No, not a good idea to remove this. In general its very usefull on laptops I 
> think. Some comments on the stuff in you blog:

Well, maybe drop was too heavy a word. See below.

> > First, there might be more than a single backlight
> - the tool which provide the interface have to handle this or the get/set 
> methodes have to take/return arrays with info for each display. But the major 	
> use case on laptops this is IMO not really needed, there is the internal 
> display the thing you want to change

Yes, this is exactly my view.

> > Secondly, exporting the brightness as percentage sucks 
> No, it does not. It make no sense to export e.g. all ~250 brightnesslevel of a 
> Panasonic laptop display. If you want to change the display brightness of 
> such a display e.g. with a slider in the GUI you produce high system load and 
> many calls to HAL/in HAL. And you can't see the difference between level 170 
> and 172. 

Totally agree.

> Mapping the existing level to percentage make much sense. This allow you also 
> to use your settings on different machines with different brightness level 
> (if you use e.g. a NFS home).

Agree.

> Btw. the mapping to percentage should maybe happen in HAL directly.

No can do, we can't do floating point maths in HAL shell script. When
everything is using the sysfs interface, maybe we can reconsider, but
until then we are stuck with shell.

> > Thirdly: you need to add a "reason" parameter for the brightness change 
> > signal. 
> Sounds sane.
> 
> > Move the backlight stuff to their own D-Bus 
> > objects: /org/freedesktop/PowerManagement/BackLighDevices/backlight0 and so 
> > on. (better use some HAL device name for naming the object)  
> 
> Make maybe sense, but why do we need these new interfaces which are somehow 
> only duplicates of the HAL stuff? Would it not make more sense to only 
> provide one interface to all display backlights (set brightness to 50% would 
> set it to all displays) or only to the primary display (would make sense on 
> laptops)? For all other interfaces you can use HAL also directly or not?

Yes, while I agree with what you say I'm thinking about the *simplest*
base specification we can define as _compulsory_. If you think about it,
we shouldn't enforce all implementers of this API to deal with
brightness, but we should make them deal with Suspend and that sort of
thing.

The next logical version of the spec would define the interface:

org.freedesktop.PowerManagement.Backlight

with Methods:

uint GetBrightness
SetBrightness uint

and make this interface optional. I can add this to the spec now if you
like.

Thanks for your help with this.

Richard.