More API breakage: battery.remaining_time

[Richard Hughes]

On Sun, 2007-01-21 at 23:24 +0100, Danny Kukawka wrote:
> > It sometimes means time to discharge when on battery, but also means
> > time to charge when on system AC power.
> 
> And what is the problem?

It breaks the abstraction. When property values are changed
non-atomically due to BIOS delays, session code breaks.

> > This concept sort of breaks in the multibattery case where one battery
> > can be discharging and not the other. It's also difficult to map to UPS
> > values where both are possible to get.
> 
> I don't see where the problem is! I have no problem with this keys.

Well, what does the time_remaining key do when one battery is 100% and
charged, and the other is at 70% and discharging? Does it take the
system AC value and decide on that, or does it take the individual
battery charging action? When the AC is added, at what point do we
remove the key and re-add it as the other state?

> > More seriously, it causes races when the user unplugs AC where the
> > sequence of events is very bios dependent. Sometimes the time_remaining
> > value is referring to the old state for a split second when the system
> > is in another case which I've had to solve for g-p-m with a 500ms
> > "valid" timeout. This is pretty icky.
> >
> > I propose splitting battery.remaining_time into
> > battery.remaining_time_until_charged and
> > battery.remaining_time_until_discharged and keeping
> > battery.remaining_time around for 1 year for compatibility with existing
> > users. This is similar to what we are doing with suspend_to_disk.
> 
> I don't understand what this should bring. What is the advantage? They can be 
> temporary incorrect in the same way as only one key. And one key provide 
> together with battery.rechargeable.is_(dis)charging as two keys. If there are 
> any problems with only one key and incorrect dates, we have to fix them 
> (maybe need to change the workflow and set better default values if the 
> AC/battery state change) and not to add new keys which don't provide more 
> information. 

Erm, the fundamental problem is we are using one key to represent two
items of information. As the AC/BAT events happen in the bios out of
order and with a small delay, the time_remaining key becomes in a
quasi-state of being valid and not valid as the checks on the battery
values is done.

> At least I hate to change them, because this also mean other ppl and projects 
> have to change code and maybe complete workflows. This isn't needed. All 
> current existing projects work also well with only one key.

So, we keep the old key for about a year until projects have switched,
like we are doing with suspend_to_disk.

All I know is doing it this way (only setting a new key when valid) and
removing the old key as we become non-valid removes the race condition
in gnome-power-manager. I don't know how you do it in kpowersave, but
I'm guessing you have some sort of delay timeout for the value to settle
too.

Fundamentally exporting two calculated lumps of data that are calculated
on one key is bad. It means we have to put logic in desktop programs to
switch the value depending on another key value.

Richard.