[patch] Fixing ACPI to ignore the special 'Ones' value

[Richard Hughes]

On Sun, 2006-10-29 at 16:53 +0100, Danny Kukawka wrote:
> On Saturday 28 October 2006 23:46, Richard Hughes wrote:
> > As discovered in : http://bugzilla.gnome.org/show_bug.cgi?id=348201
> >
> > ACPI gives out the special 'Ones' value for rate when it's unable to
> > calculate the true rate.
> >
> > We should set the rate zero, and wait for the BIOS to stabilise for the
> > few BIOS's that give 0xffff as the very first entry after an AC state
> > change.
> 
> Some comments:
> 
> 1.) you should not depend on the remaining time to shutdown the machine, but 
> on the remaining percentage which is much more reliable.

Sure, g-p-m does both, but in the split second on unplugging the machine
we have a race. If you read the bug further up, you'll see I've added a
"valid" signal in g-p-m to counteract this.

> 2.) Not sure if this fix is correct, because there could also be machines wich 
> report this value as normal and correct value (my machine e.g. report 46058 
> mW ... there is not so much until this value)

No, 0xffff is a reserved value by ACPI as unknown. It's in the ACPI
spec. This is also observed decompiling lots of DSDT's like I've been
doing recently.

> 3.) You should not change the value of battery.reporting.rate because this is 
> the value the machine report. If you would like to change a value, you have 
> to change battery.charge_level.current.

The reporting rate has already been set as a HAL property, the copy I am
modifying is a local copy that is never written back as reporting.rate,
only used in the calculation of charge_level - unless I misunderstand
the question.

Hope that helps,

Richard.