[patch] pmu patch

Thu Feb 3 08:35:01 PST 2005

On Wed, Feb 02, 2005 at 11:52:28PM -0500, David Zeuthen wrote:
> On Tue, 2005-02-01 at 19:52 +0100, Sjoerd Simons wrote:
> > Hi,
> 
> Hey,
> 
> Sorry for the lag,
> 
> > 
> >   Attached path enabled hal to read the various sensors and battery
> >   information on apple machines. 
> 
> Thanks! I just changed a lot of code so I rewrote much of your patch for
> detecting the AC adapter and batteries. As I've got a 867MHz Powerbook 12",
> not a lot of fancy stuff works (grr!) so I haven't added any of the sensor
> stuff.

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

All the stuff won't work on an Imac G5 though. According to a mail from benh:

  However, it would indeed be useful if I had, at least for some time,
  physical access (or ownership) of a new iMac G5. The chipset in those is
  new, Apple did at least one very significant change to their usual
  architecture which is the replacement of the good old PMU chip with an
  SMU one which also takes over the fan management etc...

But there isn't even kernel support for it yet so..
> 
> >   On the todo list is to convert it to using the hal utility functions
> >   instead of the nice glib ones where possible. Unfortunately the current
> >   one needs some adaption to work nicely for the pmu implementation..
> 
> I just added some more stuff to util.c and used that.

Nice
>   
> >   The biggest issue is that you i really need to get all the pmu battery
> >   information in one read to ensure sane information (i guess acpi does need
> >   this too, but it doesn't right now).
> > 
> 
> Hmm; the only thing changing (that we're interested in), at least for
> batteries, is the 'charge' entry. Also, why should this be an issue
> if we read the file a few times within a millisecond or so? Just
> curious,
> I haven't looked at the kernel source yet :-)

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.

> >   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 ?
> 
> >   There is no key for remaining time, the kernel knows how to calculate
> >   this for pmu and apm (dunno about acpi).. Would be usefull to create a
> >   key for that. Also the pmu delivers voltage and current information,
> >   which i can't place in a standard specified key..
> > 
> 
> If the kernel knows how to calculate this, so should the desktop notification
> icons using the info we export :-). This will also make it easier to change;
> it's much easier to push out a change in a desktop package than getting it
> into the kernel. 
> 
> Btw, the code in the kernel for calculating time on PMU  looks pretty
> low
> quality, at least judging from the numbers I get. I still haven't looked
> at the source, no, maybe it's just because no-one wants to write proper
> support for the 867 MHz Powerbook G4 12" :-)
> 
> 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..

> >   The code also reads the sensors avaible from the thermal control units
> >   modern apple laptops and powermacs have (maybe others too, dunno).. I've
> >   placed it in pmu file too, although it isn't really a pmu thing.. 
> >   
> 
> Yeah, I don't really know where we should put it :-). One might argue
> it's a bit cracktastic to let hal expose such information :-) - dunno;
> I'm worried about the bandwidth for exporting a lot of device objects
> with changing properties..

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.

> >   Biggest problem i'm seeing here with there is no key indicated for the
> >   value (i'm using system.sensor.value in my code currently). And there is
> >   no indication in which units these are. Imho it's best to choose standard
> >   units and let hal do the conversion when needed, just so higher leven
> >   applications don't have to do this..
> 
> Right. But sometimes we don't have the units, e.g. APM only exports a
> percentage :-). Again, I'd rather put the brains in higher level apps.

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

> >   The keyboard light sensor and lid button stuff for which i need callouts
> >   will
> 
> s/callouts/prober/ right? (much like hald-probing-input)

Well need to see what the difference is :)

> >   hopefully come later this week. 
> 
> Cool. As noted in another mail, we don't do polling of the values for either
> ACPI, PMU or APM; it would be good to find out if there's an event on
> /dev/pmu we can listen to for updating battery status. Otherwise I guess we
> just have to go ahead and play the good old polling game :-). 

I really don't think it does.. Probably we need to poll.

  Sjoerd
-- 
The following statement is not true.  The previous statement is true.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal