[Kde-hardware-devel] Missing powermanagement features in Solid

[Kevin Ottens]

Le vendredi 22 juin 2007, Sebastian Kügler a écrit :
> On Monday 18 June 2007 20:14:24 Kevin Ottens wrote:
> > Le samedi 16 juin 2007, Sebastian Kügler a écrit :
> > > > > While hacking on a Plasma::DataEngine that can potentially provide
> > > > > the necessary information for a battery applet, I found that some
> > > > > functionality is missing for the things I'd like to see implemented
> > > > > at some point.
> > > > >
> > > > > More specific, I'd like to see the following provided by Solid:
> > > > >
> > > > > - Time remaining until battery completely empty
> > > > > - Time remaining until battery is fully charged
> > > >
> > > > Not provided yet, actually I'm not sure where it's best to implement
> > > > this since this kind of information is completely unreliable, and
> > > > requires some learning on the battery behavior (which would be weird
> > > > to do in a lib imo).
> > >
> > > Well, HAL has those and I found it quite useful (gets us rid of the
> > > policy stuff, provides consistency for those that are running various
> > > powermanagement tools at the same time). GNOME's powermanager actually
> > > has some advanced heuristics to collect this data, I'm not sure if
> > > that's what we want. See for example
> > > http://hughsient.livejournal.com/28386.html
> >
> > Well, those heuristics are here because the HAL information is
> > (understandably) unreliable.
>
> The information is quite useful for me. While it might not be reliable,
> it's still a hint, and it's much more readable for the human mind as well.
> This information should IMO be provided by Solid, the 'reliability' issue
> should IMO be fixed in HAL.
>
> How about exposing this from HAL for the short term and keep in mind that
> we want to make this a bit smarter?

That's the other solution, but I'd prefer to go with Solid::PowerManager first 
as proposed below. This way we can manage the API better.

> > > Anyway, being able to get this information from HAL would be a good
> > > first step, one could drop in a better implementation of the remaining
> > > time some time in the future. The information itself is essential. Most
> > > users don't care about the percentage, that's battery dependant, they
> > > want to know how much time's left.
> >
> > Well, I'm sort of reluctant to provide such unreliable information,
> > hoping that it'll get magically sorted... in the meantime you have
> > applications taking decision using bogus information.
>
> I don't see a clear way of getting features such as "suspend when 3 minutes
> of battery life" are reached. The remaining battery capacity suffers from
> the same problem if I understand you correctly (It also decreases quicker
> when you start tuxracer).

Agreed you need such information. My point was that if it's unreliable 
your "suspend when 3 minutes left" means nothing, could be 30s could be ten 
minutes.

> > Moreover, looking at the kind of application you're working on, you're
> > not interested in having this information for a particular battery, but
> > need to compute it for all the batteries in the system. That's why I'd
> > advise to introduce this in Solid::Control::PowerManager first, since
> > it'll be used by a couple of applications only, knowing the issue at
> > hand, then when we get it right we'll be able to migrate the relevant
> > parts in kdelibs, on Solid::Battery itself (the method on
> > Solid::Control::PowerManager would then use that instead of a specific
> > implementation).
>
> Sounds sensible to me.

Ok, we'll work on it this way then.

> > Is it fine for you? Willing to work on it?
>
> I've written in total no more than 1 KLOC C++, I doubt you would want me to
> do it. :D

Ooook, so or someone steps up, or you'll have to track me and chain me to my 
chair so that I do it during aKademy. :-)
I definitely don't have the time before aKademy.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20070622/804820e1/attachment.pgp