[PATCH] frameworkd battery status reporting
neiljerram at googlemail.com
Thu Feb 25 23:30:10 CET 2010
On 5 February 2010 22:44, Neil Jerram <neiljerram at googlemail.com> wrote:
> On 14 January 2010 22:41, Neil Jerram <neiljerram at googlemail.com> wrote:
>> I've just installed Timo's kernel from
>> http://users.tkk.fi/~tajyrink/moko/kernel_20100108_nodebug_nopreempt/uImage-moredrivers-GTA02_oma-andy-2a04ce8203d7d0f1.bin, [...]
>> But I noticed two apparent changes/regressions.
>> 1. The openmoko-panel-plugin battery icon doesn't notice changes to
>> the battery charging state. I can force it to notice by clicking on
>> the icon, but it doesn't notice itself. I guess that means that the
>> dbus signals for charging status are not working.
> I think I've fixed this one. Apparently kobject notification has
> changed behaviour in the case where the /sys paths that frameworkd
> watches are symbolic links. When the Python-level notification
> callback is called, the path given is a canonical link, not the
> original symbolic link path.
I'd like to get the attached frameworkd patch upstream, if people
think it is correct. But it occurs to me that I don't recall hearing
this problem being reported by SHR users - and so I'm wondering if
that might mean that the patch isn't right for SHR.
Is the current SHR kernel significantly different (older?) from Timo's
no-debug kernel at the location above? In particular, can anyone pin
down whether it contains the same (apparent) sysfs change as described
above? (I'm afraid I haven't yet managed to find that change in the
andy-tracking git log.)
Alternatively, does SHR do battery status reporting in some completely
different way, which would be unaffected by this patch?
Thanks in advance for any enlightenment...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1054 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/community/attachments/20100225/828901e0/attachment.patch
More information about the community