Update on DeviceKit

Richard Hughes hughsient at gmail.com
Fri May 9 02:21:49 PDT 2008


On Thu, 2008-05-08 at 22:54 -0400, David Zeuthen wrote:
>  - 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.

We could expose it in X, although I'm not really sure it's a KEY. The
same can be said about kill switches.

One small comment - you probably want to do enumerated types (like in
HAL) lithium-ion, pb, lithium-polymer, etc for battery-technology - else
every client program is going to have to have a map of spaces and cases
to values.

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

Right, estimating time is hard. In gnome-power-manager we do this
per-session using the past data from the battery, the rationale is that
I have a very different usage pattern from my family. For instance, I
have the brightness set 100% and compile all the time, and my gf has the
brightness set to 60% and just uses facebook. Consequently "my" battery
lasts about an hour less than "hers".

I'm not sure hardcoding the units at Wh and W makes much sense. What
about a CSR mouse that only exports units of 1-7? There's no way to map
that to Watts.

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

Rate isn't actually that useful if you profile the battery using past
data. Rate over 1 minute is statistical noise and isn't useful in the
slightest.

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

Sure, but PowerSourceSysfs seems linux specific for little gain.

Richard.




More information about the hal mailing list