Update on DeviceKit

[Holger Macht]

On Wed 07. May - 12:11:00, David Zeuthen wrote:
> On Wed, 2008-05-07 at 13:47 +0200, Holger Macht wrote:
> > On Mi 07. Mai - 13:38:21, Danny Kukawka wrote:
> > > On Mittwoch, 7. Mai 2008, Bastien Nocera wrote:
> > > > On Wed, 2008-05-07 at 03:40 -0400, David Zeuthen wrote:
> > > > > For other subsystems, such as Firewire, audio and input my answer for
> > > > > this is to, for notifications and enumeration, rely on the core
> > > > > DeviceKit daemon and values exported by the OS kernel (e.g. sysfs on
> > > > > Linux). In effect, this is not any different from using HAL today.
> > > >
> > > > What about brightness controls
> > > 
> > > IMO powermanagement
> > 
> > Yes, I think of it like following:
> > 
> > Having a subsystem daemon for power management incuding:
> > 
> >  org.freedesktop.PowerManagement.*
> > 				.PowerSupply
> > 				.CPUFreq
> > 				.Backlight
> > 				.Sleep
> > 				.WakeOnLAN (maybe better fitting to NetworkManager)
> 
> What I have right now (IIRC) is
> 
> - org.freedesktop.DeviceKit.Power
>   - Sleep, Hibernate
> - org.freedesktop.DeviceKit.Power.Source
> 
> It's very simple. Also other questions
> 
>  - I'm in the camp that thinks we should leave backlight to X. But I'll
>    reply elsewhere on that.

For me, I don't really care ;-)

>  - Is CPUFreq still something we want?

Yes, to be able to do fine-tuning, but with a slightly different interface
that in current HAL.

>  - WakeOnLAN - probably agree to punt that to NetworkManager
> 
>  - I think we want a "composite battery" source too.. that represents
>    all the power sources on the box. Mostly because every policy agent
>    will need to do this themselves anyway.

My plan. There's currently so much intelligent code in g-p-m to handle
this, estimating time remaining etc., working more or less, but this
should be a common source.

>  - Maybe we want to record historical data in a database much
>    like DeviceKit-disks does for SMART values
>    - http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device.DriveSmartGetHistoricalData
>    I think this would be really useful; I know g-p-m already does
>    something like this. Would be useful to do it in a single place.

See above.

Regards,
	Holger