ACPI/PMU procfs HAL test program. Version 002.

[Paul Ionescu]

On Tue, 25 Jan 2005 11:59:21 +0000, Richard Hughes wrote:

> .type should remain as laptop, ups etc, as the battery object is usefull
> to other hal objects too.
> 
> .technology might be best for LI-ION|NiM|NiCad etc
>  

Ok, will put it in next patch.

>> 2) Now we are reading /proc/acpi/battery/BAT0/info or state every time
>> we search for a value which leads to increase load due to executing acpi
>> methods . A better approach would be IMHO to read that file in a buffer,
>> and look for the wanted values in that buffer. The code readability and
>> beauty should be the same, but maybe we need an extra function for this.
> 
> Sure, I must admit that I'm no expert with buffering files, but I would
> gladly take a patch to do this. Or even a URL with some details...

I'll have a look when time permits.

>> 4) For processors we need info about it from both /procfs and /sysfs,
>> so maybe we need to add a separate key like linux.acpi.sysfs_path .
> 
> Makes sense, please could you do a patch against CVS head on
> hal-spec.xml.in and you can get David to merge it.
> 
> Also when you are there, could you get rid of system.ac_adaptor.number
> and system.battery.number please as they are pretty worthless.

I do have 2 system batteries in my laptop.

>> 5) We have a BOOL system.battery.rechargeable.is_charging, and the
>> state of the battery can be: charging, discharging, charged. How do we
>> represent these three states ?
> 
> Good point. We could make it a string and make it
> charging|discharging|charged or create another bool
> system.battery.rechargeable.is_charged.

Easiest is to make it string, so I'll make it string for now and if we
decide latter that is not good, we'll change it then.

Paul

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