[Kde-hardware-devel] Solid API additions for power management
Kevin Ottens
ervin at kde.org
Tue Mar 30 20:08:13 CEST 2010
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
More information about the Kde-hardware-devel
mailing list