[SHR-Unstable] Broken Batter Applet

Tim Abell tim at timwise.co.uk
Thu Jun 25 04:44:20 CEST 2009


bump.
any news on this?
I'm having the same issue in Om2009

Paul Fertser wrote:
> 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).
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20090625/38f98781/attachment.htm 


More information about the community mailing list