bump.
any news on this?
I'm having the same issue in Om2009
Paul Fertser wrote:
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).
_______________________________________________
Openmoko community mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/community
