[patch] pmu patch

[David Zeuthen]

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.

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

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

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

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

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

>   The keyboard light sensor and lid button stuff for which i need callouts will

s/callouts/prober/ right? (much like hald-probing-input)

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

Cheers,
David

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