apm code

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)
> 	printf("unknown\n");
> 
> 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?

Best regards,
Liam Foy
 


More information about the freebsd-acpi mailing list