[patch] pmu patch

[David Zeuthen]

On Thu, 2005-02-03 at 17:35 +0100, Sjoerd Simons wrote:
> I suppose your on a TiBook then right ? The sensors stuff works on
> Albooks and Powermac G5. And probably on most other machines currently
> sold by Apple (I get to play with an minimac on friday, will let you know :)).
> 

I think it's an Albook - it's damn warm too; almost unusable - guess I
should build my own kernel with HZ set to 100. I didn't have any files
in /sys/devices/temperatures... I'm running a 2.6.10-something kernel;
mostly upstream but with some Fedora stuff in it.

<snip>

> The kernel doesn't care. The problem is that if you read it twice, there is no
> guarantee that the information you get the first time is from the same state as
> the second time. So it could well be that the first time you read, your on
> battery power with a discharging battery and the second time your on AC with a
> charging battery.

But since we're going to poll that shouldn't be a problem.

> > >   Other issues, battery.charge_level.maximum_specified is mandatory (i
> > >   can't get that info with pmu) but battery.charge_level.maximum_real is
> > >   available (which i can get).. battery.charge_level.unit can be set to a
> > >   physical unit, but isn't it better to agree it's always a certain uni
> > >   (always mWh for example and let hal do the conversion instead of
> > >   requiring every app to do
> > >   it)
> > 
> > I changed the spec and code to only have battery.charge_level.maximum.
> 
> Any decision about the unit ?

The battery.charge_level.unit property is optional so it's not set by 
the PMU stuff:-). Seriously, it's not important either for normal
desktop usage though some desktop may want to expose it.

<snip>

> > Btw, in principle I'm against letting hal relay something that is computed
> > based on the policy of an algorithm since that, uhm, is policy. I've much
> > rather wants to relay facts and leave the guesswork to higher level
> > apps.
> 
> Maybe. The other side is that calculating remaining time is something that is
> dependant on hardware. So by pushing it to a higher level you require all apps
> to know how to calculate it for certain types of hardware. Imho if the lowlevel
> stuff that knows the hardware quite well already does it for you, then use
> that..

But what if it's crap? APM "time remaining" looks like crap. OTOH, there
are
several excellent algorithms / estimators for estimating this stuff:
higher
order methods; use last N data points; all that numerical analysis and
scientific computing stuff (I can't remember anyting about it though, as
I haven't looked at it  since the courses I took back in 1997 :-) - and
my books are all back in Denmark).

We're basically discussing this: should the switch (whatpowersystem) be
in hald or in the desktop notification applet? What if GNOME wants 
estimation method A and KDE wants estimation method B? 

<snip>

> No reason to not do something because it requires fixing hal right ? Battery
> and sensor informations are some the things i would really love to have in hal
> 0.6.x.. Because it makes writing nice highlevel apps for them so much easier.

We should definitely show the presence of sensors. I'm not totally
against
us providing things like temperature either.

<snip>

> Sensors are a little diffent from batteries ofcourse. Most of them do actually
> give out units. But ofcourse it could be that a sensors gives out just 
> percentage, so if we only get that and don't have extra knowledge then that's
> what the user app sees. 
> 
> OTOH if we just get a percentage from the sensor, but we have some extra
> information (As in it scales linear between 0 and 2000rpm).. Do you want every
> high level application to carry that information? I can assure you they won't,
> that's why we have a big pile of highlevel sensor apps which only do one kind
> of sensor (which sucks!).. Seems to me like hal is a nice central place for
> that info

We should just provide a current, maximum and unit with unit (and
perhaps
maximum) being optional.

David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal