[Kde-hardware-devel] Solid API additions for power management

[Kevin Ottens]

On Friday 19 March 2010 15:45:24 Dario Freddi wrote:
> After looking into upower, there are surely some API additions I would like
> to make taking advantage of the new features.

At that point I would aim at not extending the API and making the new upower 
backend at the same time. So please concentrate on having the backend running 
first. I'll still comment on the proposed additions as there's a few 
interesting ones in there, but don't consider this as a free pass to add them 
(yet!). :-)

> Here they come:
> 
> qreal energyWhenFull() const; // Energy capacity of the battery in Wh
> qreal energyWhenFullByDesign() const;  // Energy capacity of the battery in
> Wh as shipped by the vendor
> 
> qreal currentDrain() const; // Current battery drain in W
> 
> qreal voltage() const; // Current battery voltage in V

What would be the use case for all those? Note that HAL was able to report 
something similar but it was previously left out on purpose. The idea was that 
it wasn't useful to most apps, except something like powerdevil, I think this 
80/20 rule still apply but we could choose to revisit this particular case.

> int timeToFullCharge() const; // Time remaining for the battery to be fully
> charged

Same remarck than above. And also note that this one has been controversial in 
the past (the whole "predictability" issue, discussed at lenght in plasma-
devel actually).

Now, I think that upower has a much better markov chain based model (IIRC) to 
do that, and that's the opportunity I was waiting for to get this info 
reported. Please check on the reliability of it before exposing it.

> Technology technology() const;
> in pair with
> enum Technology {
> Lithium,
> NickelCadmium,
> etc.... };

Use case? This one really I don't feel like it can be of any use, only use I 
see would be reporting in a UI to the user, who really doesn't care about 
that.

> An addition to Battery::BatteryType enum of
> PhoneBattery, MonitorBattery

This one are OK to go. You can even add them now if you want.

> More than this, upower is also able to show if the battery has been
> recalled by the vendor. To do this, I thought about doing the following:
> 
> bool isRecalled() const;
> RecallDetails *recallDetails();
> 
> and provide a new RecallDetails class carrying the details.

Again, use case?

> --
> 
> upower features some additional features that I really don't see useful at
> the moment (for example, the current amount of energy in Wh), but I'd like
> to throw those in.
> 
> The problem is where. I see some of them a good candidate for
> Solid::Battery, whereas some others might well go into Solid::Control or
> whatever it will be in the future. What do you think makes sense where?

The split we currently have is the following:
 - Discoverability of devices in libsolid
 - Properties for general application consumption in libsolid
 - Properties for specific policy agents (e.g. powerdevil) consumption in 
libsolidcontrol

Now we're aiming at having libsolidcontrol disappear. So this extra specific 
introspection would have to happen in the policy agents themselves now (but 
really that's because we're rolling back libsolidcontrol in each of them). The 
"right way"(tm) to do that IMO would be for said policy agents to query the 
device via Solid::GenericInterface (key/value based) for the extra info 
needed. Obviously requires the backend to implement it, in which case it can 
expose pretty much everything it wants through this mean.

That's obviously backend specific code, but you can make a small wrapper 
interface which maps methods to keys. That'll give you the extra level of 
indirection you need in the policy agent to be portable and to provide 
different mappings depending on the backend.

We're obviously missing one bit in libsolid though: the ability to know which 
backend is responsible of a device. That's a price I'm willing to pay (one 
method in Solid::Device) if that avoids us cluttering a lot of interfaces for 
only one application use.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100330/9bd0ba42/attachment.sig