Update on DeviceKit

[David Zeuthen]

Hi,

On Wed, 2008-05-07 at 12:03 -0400, David Zeuthen wrote:
> On Wed, 2008-05-07 at 12:58 +0200, Holger Macht wrote:
> > Hi David,
> > 
> > good to hear some news ;-)
> > 
> > On Wed 07. May - 03:40:04, David Zeuthen wrote:
> > [...]
> > > Also, we need subsystem daemons for USB and for power management. For
> > > PM, I have some code lying around that I never put in git. I'm going to
> > > try and clean it up over the next week or so and post it here. 
> > 
> > Can you give me a short hint what your PM code includes? I already took a
> > look at DeviceKit and already tought about the conversion of the PM bits.
> 
> Yeah, it's basically just
> 
>  - an XML file describing the interface, just like this
>    http://gitweb.freedesktop.org/?p=users/david/DeviceKit-disks.git;a=blob;h=f961193583407444a4452773e9fe032797b699a7;hb=61fd98cfa4478e4a564b5cf225e4100f002ee650;f=src/org.freedesktop.DeviceKit.Disks.Device.xml
>  - which is used to autogenerate something like this
>    http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html
>  - Some daemon code just like in DeviceKit-disks to trawl sysfs values
>    and set properties.
> 
> It's really simple and clean code. The code is on some machine at home
> powered off (I haven't touched it for several weeks); let me clean it up
> and post it tonight or tomorrow.

OK, here we go, I've checked this into version control and cleaned it up
a bit more

 http://hal.freedesktop.org/docs/DeviceKit-power/
 http://gitweb.freedesktop.org/?p=users/david/DeviceKit-power.git

It's pretty much like the other two daemons; there's a daemon, XML
descriptions, a small devkit-power tool and man pages.

Other thoughts

 - How do we want to handle lid (and other) switches? Do we assume that
   it's exposed through X? While that may be true on Linux, I'm not sure
   you can generally assume this. It might be better to export a .Switch
   interface for each switch we encounter. I don't know.

 - I've intentionally left out a lot of stuff that the _hardware_
   normally exposes such as voltage, reporting of raw values etc. The
   rationale here is that we put a lot of brains into this service to
   use history etc. to help estimate values. Maybe you and/or Richard
   has some reasons why this is crack; you guys know more about this
   than I do. So input welcome.

   - it would probably make sense to have properties battery-rate-1min, 
     battery-rate-5min and battery-rate-15min that expresses the rate
     averaged over time. Perhaps ditto for the time until empty, full
     properties. I don't know.

 - Right now there's a simple .Source interface. Perhaps it would make
   more sense to split this into two interfaces. On the other hand, for
   the composite stuff, perhaps we want to export a single source with
   type "composite" and then both line-power-* and battery-* properties
   are valid.

 - Should probably have a PowerSourceSysfs and PowerSourceUSBHidUPS
   subclasses. I can look into that while implementing the HID UPS
   stuff. Would also make it easier to port this to other OS's.

      David