FS#9572 - hal reports batteries duplicate + sysfs battery doesn't update
Attached to Project:
Arch Linux
Opened by Loic Nageleisen (lloeki) - Thursday, 14 February 2008, 09:36 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 14 May 2009, 05:23 GMT
Opened by Loic Nageleisen (lloeki) - Thursday, 14 February 2008, 09:36 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 14 May 2009, 05:23 GMT
|
Details
Description:
since we have both /proc/acpi and /sys enabled in the kernel for battery information, hal mistakenly thinks there's two. also, hal sysfs code does not poll every 30s like for proc. so if we use only sys, we break not sys-aware software like xfce panel applet. besides, as it is not polled by hal, the sys information is not reliable. also, whether we use only sys or both sys and proc, the sys information will have side effects on hal-aware application behaviors, even with proc enabled: the information will be the same as when hal was started, thus on a discharging scenario it will report a non-existent potential charge when in fact we're hitting the red zone (as correctly notified by proc) of the very same battery, thus we may hit power shortage issues because of wrong information (that is there's a backup battery with power left available, so supposedly no need to shutdown) therefore I suggest to disable ACPI_SYSFS_POWER for now (it's at best unreliable anyway) and leave only ACPI_PROCFS_POWER, at least until we have the updated hal in extra. Additional info: fixed upstream in git. see http://dkukawka.blogspot.com/2008/01/hal-sysfs-acpi-batteries-fixed.html |
This task depends upon
http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=4541abd23fd02118a1a7f8b825aed338d2a5d638
$ cp -R /var/abs/extra/system/hal ./
$ cd hal
$ git clone git://git.freedesktop.org/git/hal
$ mv hal hal-0.5.10
$ tar cfz hal-0.5.10.tar.gz hal-0.5.10
$ sed -i "s/md5sums=('.*'/md5sums=('$(md5sum hal-0.5.11.tar.gz | cut -d ' ' -f1)'/" PKGBUILD
$ makepkg
# pacman -U hal-0.5.10-1-i686.pkg.tar.gz
# /etc/rc.d/hal restart
If more information is needed, just say something that I'll send it right away.
Now sysfs battery information updates (every seconds or two), although it seems its information might be incorrect, because my laptop shuts down when I have 15% of battery charge.
There's still two batteries showing up, don't know if it's because we use both /proc and /sys or if it's a kernel bug, because both /proc and /sys shows two batteries while they should be showing only one (I think...).
I'll check the kernel changelog from 2.6.26.2 to 2.6.26.3 to find what happened.
HAL still shows 2 batteries (even if none is connected), my laptop shuts down (hard shutdown, not the normal process) when HAL shows there's still 15-17% of battery charge, but when I power on the laptop right after, it shows 0% of charge.
HAL doesn't seems to recognize when I pull off the battery, although he knows when I plug it in.
The first affirmation is based on information from g-p-m, conky, /proc and /sys, and the second from g-p-m only. I'll try to see if lshal does send/receive an event when I plug in/out my battery.
I'm afraid that the first problem (2 batteries and charge incorrect) are because of the kernel or from my battery, because both /proc and /sys should show the correct information.
For now I can live with this issue, but in a month or so, I'll work on it, because I really don't have any free time for now.
Although, I appreciate if someone could tell me how to catch acpi events, or which log file normally contains this events. Also need to know where to look for my battery charge, besides conky and HAL.
Neither conky or g-p-m have correct battery information.
If I read the battery charge through SYSFS (/sys/class/power_supply/BAT0/charge_now), the charge is incorrect (doesn't get updated), so every HAL-dependent application have incorrect information.
If I read the battery charge through PROCFS (/proc/acpi/battery/BAT0/state), the charge is correct and application using PROCFS (like conky) gets updated, but doesn't get automatically updated unless I read the file again. The battery status in SYSFS also gets updated, so every HAL-dependent application have the information updated.
I think it kind of worked before because I was running the acpi daemon, which was getting all information from PROCFS and probably was updating SYSFS. But this daemon shouldn't be necessary, SYSFS should update every 30s the battery status, and HAL would then get the events from D-Bus every 30s and update every application depending on him.
I forgot to say that I don't have the following modules loaded: ac, battery, bay, container, acer-wmi. I explicitly blacklisted them in rc.conf because only the sbs module is required so my battery and ac-adapter can work.
I've been searching a lot about how HAL works with ACPI and found the following: HAL doesn't need acpid to be running, it can listen to /proc/acpi/event by himself, but if acpid is running, it will listen to /var/run/acpid.socket. The problem is, with or without acpid, all events get caught but the battery charge. I believe it must be acpid or HAL to be polling the battery to know those values, but it's not happening.
The only way to get updated battery charge is to cat /proc/acpi/battery/BAT0/state or create an ACPI event like plugging the AC Adapter, then the info in sysfs gets updated, conky gets updated and HAL gets updated. By the way, HAL polling does work, but because it's listening to sysfs, it doesn't get any new value, that's why when running lshal -m I don't see the polling "happening".
Well, hal may not be needing acpid but it's automatically being started by hal on my system. /proc/acpi/battery/BAT0/state doesn't get updated here so cat'ing it is a no go here.
Honestly. I'm getting slightly confused by now. Is this issue related to hal, acpid or the kernel?
Any suggestion on what to do?
Added url to a topic I made as I think it's related. http://bbs.archlinux.org/viewtopic.php?id=63305
Cheers.