Created attachment 13124 [details]
lshal

Created attachment 13125 [details]
kernel config

I already know that and work on a solution ...

Looks like this has been fixed with http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=4541abd23fd02118a1a7f8b825aed338d2a5d638

The OP mentioned two problems, that patch seems to fix the first one, but does it really solve the second problem:

>It also seems that using the new kernel API, the state of the battery is not
>updated properly.

(In reply to comment #5)
> The OP mentioned two problems, that patch seems to fix the first one, but does
> it really solve the second problem:
> 
> >It also seems that using the new kernel API, the state of the battery is not
> >updated properly.
> 

if lshal | grep -i bat should display current battery values, it is wrong.

lshal | grep -i bat shows different values from sysfs interface. 

I noticed that these values get reloaded at an acpi event (reloaded by hal, directory content is updated on the fly).

This all is fixed. Since the kernel send no signal if the battery values change (because the values get read from the hardware and set in sysfs in the moment you read a file there) HAL do the same as before with proc: read battery values every 30 seconds which is often enough. 

There is evidence gathered by Daniel T Chen that this bug still exists. We're discussing this here: https://bugs.edge.launchpad.net/ubuntu/+source/hal/+bug/194719
where you can also find log reports.

To be clear WRT Sense's comment above, the symptom described in the title of /this/ bug report is resolved by the changeset referenced in comment #4, but as comment #5 states, the battery state is not updated from sysfs properly.

(Noted that these symptoms are fixed in hal.git but not in Ubuntu Hardy's current hal source package.  Adjusting Ubuntu bugs as per necessary.  Sorry for the noise, thanks!)

(In reply to comment #7)
> This all is fixed. Since the kernel send no signal if the battery values change
> (because the values get read from the hardware and set in sysfs in the moment
> you read a file there) HAL do the same as before with proc: read battery values
> every 30 seconds which is often enough. 
> 

I think you should consider to make the poll interval configurable or put some heuristics, e.g., poll every 2 minutes when battery is above 50%, poll every 1 minute when battery is above 10% and poll every 10 seconds otherwise.

there is a typo in hal-0.5.10/hald/linux/device.c

line 3181:

/* CURRENT: we prefer the average if it exists, although present is still pretty good */
        if (!hal_util_get_int_from_file (path, "current_avg", &current, 10)) {

should be:

/* CURRENT: we prefer the average if it exists, although present is still pretty good */
        if (hal_util_get_int_from_file (path, "current_avg", &current, 10)) {


(i.e., negate the condition otherwise rate is not ever updated.)

(In reply to comment #11)
> I think you should consider to make the poll interval configurable or put some
> heuristics, e.g., poll every 2 minutes when battery is above 50%, poll every 1
> minute when battery is above 10% and poll every 10 seconds otherwise.

No, we don't make the interval configurable and we also don't change the interval depending on the situation. We use 30 sec. as we did already since ages. This interval was never a problem. To poll more often cause battery power, since there are machines where this need CPU power. Polling less often only lead to less interactivity for the user and possibly more unreliable remaining percentage and specially remaining time.

I/we work since several years on powermanagement under linux and the 30 sec. interval is IMO the best compromise.

(In reply to comment #12)
> there is a typo in hal-0.5.10/hald/linux/device.c
[...]
> /* CURRENT: we prefer the average if it exists, although present is still
> pretty good */
>         if (hal_util_get_int_from_file (path, "current_avg", &current, 10)) {
> 
> (i.e., negate the condition otherwise rate is not ever updated.)

I take  a  look at this issue.

the change has broken the GetBrightness calls on dell latitude laptops, bug #14797 is about the issue 

(In reply to comment #14)
> (In reply to comment #12)
[...]
> > (i.e., negate the condition otherwise rate is not ever updated.)
> 
> I take  a  look at this issue.

This was already fixed (2008-02-05). Close the bug now.