only polling in HAL acpi code?

[Davyd Madeley]

Quoting David Zeuthen <davidz at redhat.com>:

> (Btw, battstat suffers from this too in the very typical usecase:
> suspend while plugged in, plug out and leave the office, come back home
> and resume and battstat shows that the laptop is plugged in.)

Yeah. This is known, we were trying to come up with a better solution then to
double the amount HAL polls each time, but alas one doesn't not exist. Some
laptops are better then others, the Toshibas seem to cache ACPI events from
when they were asleep (so it gets the power button event and shuts down,
requiring some debounce to be added to the powerbtn event script).

>> >> You should also be aware that the remaining time calculations you are
>> >> doing are going to fail on some dual battery systems it seems, where
>> >> only one battery has a discharge rate listed. GNOME Bugzilla
>> >> (http://bugzilla.gnome.org/show_bug.cgi?id=309944) has a pretty good
>> >> example of how messed up this can get on dual battery systems. Notice
>> >> how all values are in mA rather then mW and that only one battery has a
>> >> discharge rate, which is obviously meant to be applied to both of them.
>> >> I'm not sure how you're going to deal with this in HAL.
>> >
>> > So, basically we treat each battery as a separate unit and e.g.
>> > battstat-applet-2 should add up time remaining. It sounds like a useful
>> > convention to use the discharge rate of the first battery if it's
>> > missing for the second (patches are welcome). The right place to fix
>> > this, however, is of course in the kernel.
>>
>> I think the kernel is nominally correct, in that it's reporting what
>> ACPI tells
>> it, which is one battery is discharging at a known rate, and the 
>> other is not.
>> The problem is that this makes the time_remaining property pretty 
>> useless from
>> an ACPI point of view.
>
> Well, HAL should be smart (since the kernel isn't) and just use the
> discharge rate of the other battery or something else that is clever
> (see below), no? I think it should as it still makes sense to discuss
> "time_remaining", e.g. sooner or later the battery will die.
>
> The key here is to put all the various work-arounds, vendor/
> model-specific hacks, and clever code in one place: HAL.

100% agree. This is why we were so excited about the HAL backend becoming
available. There is a lot of duplicated effort when it comes to ACPI handling,
not to mention all the other power backends.

>> The interesting thing here would be to know how APM is
>> returning the remaining time on dual battery systems (I seem to 
>> recall you can
>> still get separate battery state with APM).
>
> Nope, the data you get back from APM is for the entire system. IIRC,
> this is one of the things ACPI "fixed", and, btw, it is often mentioned
> as one of the benefits of moving from APM to ACPI (that and also that S3
> works on only 80% of all models :-).

Ok. I've never used a dual battery laptop on APM, but I do seem to recall
someone's Dell was able to show both batteries with the `apm` command. 
That was
in the deep dark past however, so my memory is fuzzy.

>> Otherwise, it is no major hassle to move the time calculations back into
>> battstat (we already have the code to do this). It would be nice to
>> simply have
>> this information in HAL though. I'm not 100% sure how to handle it. Some
>> batteries may report discharge rates for each battery, again there is no
>> consistency in ACPI.
>
> It would seem sane to me that each battery have a separate (likely
> different) discharge rate since the batteries have different physical
> characteristics (mainly because of difference in age and thus effective
> capacity). ICBW though, that entirely depends on how the batteries are
> hooked up to the system; I don't know if there is a standard for this
> though - just speculating.

Indeed, the batteries do have different discharge rates, the problem is 
when one
is discharging and one is not (it's discharge rate is 'unknown') so 
you're faced
with an equation you can't compute.

> Ideally, battstat shouldn't care about discharge rates and stuff like
> that; all it should do is add N numbers signifying time left (one for
> each battery) and show the total as nice graphics :-)

Yeah. Agreed, this is how the new HAL backend in battstat works. It doesn't do
any thinking for itself.

> Another point is that we may be able to do more accurate computations of
> time remaining than the 1th order linear approximation used. In fact, we
> could probably even do pretty well even if we didn't have the rate (by
> employing knowledge of how the curve looks). Patches welcome for
> that :-)

I've been thinking about this on and off for a while. Battery discharge is
almost linear, it might be sufficent to simply take a 4-point moving 
average of
the discharge rate to smooth out fluctuations in the discharge rate. I might
have to hook something into HAL that graphs my battery voltages, power and
power rates to have a look at it.

--d

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal