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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
