[gpm] Batteries and Abstraction: What Belongs in HAL?

["Stu Hood" <stuhood gmail com>]

While looking through gpm bugs, I noticed Richard's comment on bug #345954, where he mentions that he is working on more intelligent battery status code. Its a few months old, so my first question is whether or not it is still being worked on. Secondly, if the battery status code might be about to undergo a major change: 
what parts of the gpm code could and should be moved into HAL?

For instance, the only useful charge rate data currently being reported by HAL is in the "
battery.charge_level.rate" key, which exposes a raw rate from the hardware. But isn't this supposed to be the hardware _abstraction_ layer? We could certainly move some of the intelligence of our current code into HAL: such as a key for smoothed_rate (calculated with an exponential average, or with the heuristics code Richard is working on). It would make a lot more sense to have that key exposed to a desktop than it does to expose a raw number which comes straight from the hardware. Additionally, the remaining time calculations we currently do in gpm (and which will be done in the future by Richard's heuristics code) could take place in HAL, and be exposed as keys.

Use Case: A new mobile device is being developed with a kernel supported by HAL, and the developers decide to use HAL to abstract their hardware. They are about to write code to keep track of the battery charge and do time calculations based on the rate reported by the battery, but luckily the HAL and gpm developers have already implemented this logic. The developers can jump straight to putting a native GUI on the provided data, without duplicating any effort.

The root of this question is: how much of the code in src/gpm-power.c belongs in HAL? Should HAL stay lite and keep giving out raw numbers, or should it bulk up and get smarter?

Stu Hood