OLPC battery class
Richard Hughes
hughsient at gmail.com
Tue Jun 19 10:55:04 EDT 2007
Hi,
I've been looking at adding OLPC battery support into HAL so it can be
used with OHM and the power meter in sugar.
Putting it bluntly, the "generic battery class" is a bit of a misnomer,
as it's very OLPC specific. It also violates key sysfs rules such as
one-value per file, and it's not going to be pretty adding the current
battery/ac_adapter interface to HAL.
So far we have:
capacity_percentage 13
current 940
name OLPC Battery
status present charging
status_cap present low full charging discharging overtemp critical
technology NiMH
temp1 29101
temp1_name battery
temp2 48753
temp2_name ambient
type battery
voltage 7101
Specific problems:
* 'capacity' is probably the wrong word to use, in common use it means
the battery capacity compared to when nit was new, to measure how the
battery has degraded over time.
* 'status' and 'status_cap' violate the one-value-per file mentality of
sysfs. This means we have to do string processing in HAL, rather than
just read the value of a flag. status_cap shouldn't be used at at all -
if the capability does not exist to report this, then do not export the
attribute (so no file in sysfs). See below for an example.
* 'temp1' - why not temperature_ambient?
* 'temp2' - why not temperature_internal?
* Why is the AC adapter exported as a battery of type ac? This is simply
wrong, they are _completely_ different types of device.
So, I would envisage a generic battery class to look like (munging
together OPLC and acpi stuff for the example):
***** BATTERY CLASS *****
description OLPC Battery
present 1
charging 1
discharging 0
over_temperature 0
percentage 13
technology NiMH
internal_temperature 29101
ambient_temperature 48753
voltage 7101
current 700
charge_now 940
charge_design 1100
charge_last_full 997
charge_unit mAh
model_number X2344
serial_number 300360
vendor Sanyo
***** AC CLASS *****
present 1
description OLPC AC Adapter
Now, I'm prepared to put my money where my mouth is and offer to rewrite
the kernel code to the above, and then write the (now trivial) HAL
interface for this. Any problems/comments?
Richard.
More information about the Devel
mailing list