On 04/20/2014 09:09 PM, Pavel Machek wrote:
Hi!
I just glance wmbattery code. I find the code in the acpi.c is already
using the new sysfs battery interfaces, right?
By default, wmbattery appears to default to using upower as abstraction
level, instead of querying sysfs itself directly.
http://git.kitenet.net/?p=wmbattery.git;a=blob;f=autoconf/makeinfo.in;hb=HEAD
which sets USE_UPOWER=1 by default.
If USE_UPOWER=0 is set explicitly for the build, it reverts back to
direct sysfs parsing - and yes, it does appear to adhere to the current
sysfs API properly.
The last remains, and the ability to parse procfs (which hasn't been
default for quite some time already, in favour of using hal as
abstraction layer) has finally been removed in
http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=833eb63a5ce4f2fb712a201b1db4f2db1700fddb
The switch from procfs parsing to hal (by default at least) in turn
happened with
http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=63c3d1a0b11e8ade1a5612bb5baa3d92e153bbbe
in 2008 (before Debian squeeze/ oldstable). I have not investigated if
hal then read from procfs or sysfs, but wmbattery at least didn't read
from procfs itself, unless explicitly told to do so (USE_HAL=0) during
the build since mid 2008.
The current version of wmbattery however will never try to access
/proc/acpi, the current version no longer knows of its existence.
[Again, I'm not familiar with wmbattery myself and have never run it]
Stefan,
Thanks for looking into this. The newest wmbattery version indeed
supports upower. However, I haven't figured out how to get it to work.
That's obviously not the kernel's fault, but an unfortunate reality.
It seems to really want dbus to be running, but when I start dbus
(which nothing else on my system needs, apparently), it just hangs. My
knowledge of these things is, (un)fortunately non-existent, so I just
gave up on the upower approach. Running something as heavy as dbus
just for a silly dock app seems... silly as well.
Any news on this one?
It seems that delaying fsck on battery power also relies on
/proc/acpi/battery...
Ok. I will prepare a patch to recover /proc/acpi/battery.
https://bbs.archlinux.org/viewtopic.php?id=12168
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
