Liam J. Foy
liamfoy at sepulcrum.org
Thu May 20 15:29:52 PDT 2004
On Thu, 20 May 2004 15:03:56 -0700
"Grover, Andrew" <andrew.grover at intel.com> wrote:
> > Just writing to the list to make sure am correct here. The
> > issue concerns /usr/src/usr.sbin/apm/apm.c.
> > --- /usr/src/usr.sbin/apm/apm.c Thu May 20 20:30:57 2004
> > +++ /hd2/apm.c Thu May 20 20:44:36 2004
> > @@ -174,7 +174,7 @@
> > printf("Remaining battery life: ");
> > if (aip->ai_batt_life == 255)
> > printf("unknown\n");
> > - else if (aip->ai_batt_life <= 100)
> > + else if (aip->ai_batt_life >= 0 && aip->ai_batt_life <= 100)
> > printf("%d%%\n", aip->ai_batt_life);
> > else
> > printf("invalid value (0x%x)\n", aip->ai_batt_life);
> > The above patch will make apm print invalid value when
> > ai_batt_life does not equal 0-100. The reason for this was
> > the the current code was printing -1 as a so called valid
> > value(normally when acline is connected). I dont think
> > printing -1 is correct, and really it should be printing
> > invalid value since that is what it is. Do you guys agree
> > with me or does -1 symbolise something?
> if (aip->ai_batt_life == 255)
> The above line should catch the -1 case. There's a uint/uchar sign
> extension problem. Changing the 255 to -1 will probably fix things.
> Regards -- Andy
Hmm, 255 would incline that it is not supported by the device, not that an invalid value has been returned in which -1 is. I have been looking into it, and -1 is returned from apm -l when the acline is connected, and the actual percentage when it is not(showing the device supports it and 255 does not catch the returned -1). I think we need to test the percentage like my patch does.
What do you think?
More information about the freebsd-acpi