dmi_scan: vaio apm byte-swab bug - recalculation possible?

dmi_scan: vaio apm byte-swab bug - recalculation possible?

Post by Jose » Wed, 06 Nov 2002 21:53:30



Hi!

I have a Sony VAIO SR33 which has the usual
swab_apm_power_in_minutes problem, i.e. in dmi_scan.c the following has
to be added:
{ swab_apm_power_in_minutes, "Sony VAIO", {     /* Handle problems with
APM on Sony Vaio PCG-SR33 */
                       MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"),
                       MATCH(DMI_BIOS_VERSION, "R0211D1"),
                       MATCH(DMI_BIOS_DATE, "05/30/01"), NO_MATCH
                       } },
now the problem: I really would like to use standard redhat-kernels that
can easily updated via up2date etc and not bother with compiling the kernel
after every update/change of system etc. So my question: is it possible
to recalculate the correct remaining battery estimation from the incorrect
output of apm -m under the unpatched kernel?

The relevant commands in apm.c seems to be:
    if (apm_info.get_power_status_swabinminutes) {
                *life = swab16((u16)edx);
                *life |= 0x8000;
So if I take the incorrect minute-time and swab16 it (what does
swab16 do? change the a+b*16 to b+a*16?) and then OR it with
0x8000, do I get the correct time?? But that can't be right, since
because of the |= 0x8000 I would _always_ get an enourmous
remaining time?? What am I doing wrong here?

btw, here is a sample of apm output:
first the real remaining time (calculated post mortem, of course)
then the remaining percentage displayed by apm (which seems reasonable)
then in () the displayed remaining minutes (which are mysteriously
"swabed"!?)

 69 34% (243)
 66 31% (243)
 52 12%  (85)
 46 11%  (60)
 45 10%  (81)
 44  9%  (68)
 39  8%  (68)
 31  7%  (51)
 30  6%  (51)
 28  6%  (51)
 27  6%  (46)
 26  6%  (42)
 25  5%  (38)
 24  5%  (38)
 23  5%  (38)
 22  4%  (34)
 19  4%  (29)
 18  4%  (25)
 17  3%  (25)
 16  3%  (25)
 15  3%  (21)
 14  3%  (25)
 13  3%  (21)
 12  3%  (21)
 11  3%  (25)
 10  3%  (21)
 9   2%  (17)
 8   2%  (17)
 7   2%  (17)
 6   2%  (12)
 5   1%  (12)
 4   1%   (8)
 3   0%   (4)
 2   0%   (4)
 1   0%   (0)
 0   0%   (0)

So just to make it clear my question once again: Is there an
algorithm to get the intended remaining battery guess from
these strange numbers in ()? Or is the mapping
mysterious bytes -> minutes displayed by apm not injective?

Any comment appreciated,

Josef