[SHR-Unstable] Broken Batter Applet

Paul Fertser fercerpav at gmail.com
Sun May 31 11:31:10 CEST 2009

Robin Paulson <robin.paulson at gmail.com> writes:
> 2009/5/26 Thomas White <taw at bitwiz.org.uk>:
>> I found that as well.  Is anyone able to comment on what HAL is being used for
>> in SHR-Unstable?  If it's simply been pulled in as a dependency (e.g. for
>> X.org) and isn't actively being used (e.g. by X.org for input management),
>> then it can be removed without breaking anything, which makes the problem go
>> away.
> hal appears to be a dependency of xserver-kdrive-fbdev and
> xserver-security-policy; is it actually critical for these packages,
> or is thomas' assessment correct?
> i'm getting the same problem of reported charge

This is a problem that needs to be fixed. For the time being it can be
easily workarounded by using "internal" method for the battery applet,
but a proper long-term solution is yet to be found.

For that one needs to contact HAL guys and ask them about how exactly
they recommend to use their battery-monitoring interfaces, both from
upper level (how an application should deal with current situation
where we have 1 apm emulation for the battery, one usb power supply
(that according to the hal sources is also considered a battery) and
one "real" battery) and a lower layer (that "real" battery monitoring
doesn't work because E's battery gadget assumes the presence of some
sysfs properties that our driver lacks, OTOH i couldn't find any
document describing which sysfs nodes really must be present to be
compliant and which are optional).

Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav at gmail.com

More information about the community mailing list