ACPI/PMU procfs HAL test program. Version 002.

[Richard Hughes]

Paul Ionescu <i_p_a_u_l <at> yahoo.com> writes:
> I have some more comments:
> 
> 1) I have put in system.battery.type key the real type of the battery from
> the info file (LION), and not "primary" or "laptop" as per HAL specs. Is
> this ok ? Should we add another key for this value ?

.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
 
> 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...
 
> 3) My patch only reads battery options if there is actually a battery in
> that slot. Is this ok ?

Makes sense. Thanks.
 
> 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.

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

Up to you.

Richard.




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