Bug 13669

Summary: The same battery is reported twice when using linux 2.6.24
Product: hal Reporter: Matthieu Baechler <m.baechler>
Component: haldAssignee: Danny Kukawka <danny.kukawka>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: erik.andren, khashayar.lists, mh+freedesktop, sense, xhejtman
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: lshal
kernel config

Description Matthieu Baechler 2007-12-15 05:49:40 UTC
On my laptop, since I use linux 2.6.24-rc4, my battery's state is reported through 2 differents API by the kernel.
HAL doesn't understand that it's the same battery, and publish two battery on my laptop.

It should report only one battery, using whatever API it likes.

It also seems that using the new kernel API, the state of the battery is not updated properly.
Comment 1 Matthieu Baechler 2007-12-15 05:50:32 UTC
Created attachment 13124 [details]
lshal
Comment 2 Matthieu Baechler 2007-12-15 05:50:58 UTC
Created attachment 13125 [details]
kernel config
Comment 3 Danny Kukawka 2007-12-16 14:50:08 UTC
I already know that and work on a solution ...
Comment 4 Mike Hommey 2008-02-03 04:08:16 UTC
Looks like this has been fixed with http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=4541abd23fd02118a1a7f8b825aed338d2a5d638
Comment 5 Khashayar Naderehvandi 2008-02-14 04:48:32 UTC
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.

Comment 6 Lukas Hejtmanek 2008-02-27 07:55:33 UTC
(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).
Comment 7 Danny Kukawka 2008-02-28 01:00:41 UTC
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. 
Comment 8 Sense Hofstede 2008-02-28 08:31:50 UTC
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.
Comment 9 Daniel T Chen 2008-02-28 10:25:43 UTC
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.
Comment 10 Daniel T Chen 2008-02-28 14:38:17 UTC
(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!)
Comment 11 Lukas Hejtmanek 2008-03-01 10:04:57 UTC
(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.
Comment 12 Lukas Hejtmanek 2008-03-01 12:16:02 UTC
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.)
Comment 13 Danny Kukawka 2008-03-01 14:33:29 UTC
(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.

Comment 14 Danny Kukawka 2008-03-01 14:34:31 UTC
(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.
Comment 15 Sebastien Bacher 2008-03-03 14:57:39 UTC
the change has broken the GetBrightness calls on dell latitude laptops, bug #14797 is about the issue 
Comment 16 Danny Kukawka 2008-03-04 07:21:16 UTC
(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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.