Robin Paulson <[email protected]> writes: > 2009/5/26 Thomas White <[email protected]>: >> 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:[email protected] _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
