[patch] pmu patch

Thu Feb 3 10:04:30 PST 2005

On Thu, Feb 03, 2005 at 12:10:35PM -0500, David Zeuthen wrote:
> 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.

If it's an albook and you don't have that info, i'm not surprised it it runs
hot.. The module that exports that information is also responsible for turning
your fans on.. (Simple check, the albook has all it ports on the sides, while a
tibook has some at the back behind a small lid)

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

I don't see how this solved the issue.
> 
> > > >   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.

Yeah, that's why i'm asking.

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

All current apps use that afaik, so it's probably not that bad..

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

Yep.. And how many apps are going to implement that your guess ? :)

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

I don't think it's likely that GNOME and KDE will disagree on something like
that. From what i've seen most of these applications don't really care about
how the info was generated, as long as then can get them in an easy way..

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

Well then still.. An app can get the precense of a sensor through hal, but
still needs to know how to get and interpret of all different types. Which
leaves us in the same sucking situation as we're currently in..
> 
> <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.

And the way the it scales.. Well the discussion stays the same. If hal has all
the details and can potentially handle them, why require a highlevel app to
handle them (which requires code duplication for all of them...)?   

  Sjoerd
-- 
Everything ends badly.  Otherwise it wouldn't end.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal