Re: [PATCH] frameworkd battery status reporting

2010-05-01 Thread Neil Jerram
I previously wrote about some problems that I observed when switching
from odeviced to fsodeviced, and I think I can now explain those
better:

On 28 February 2010 00:44, Neil Jerram neiljer...@googlemail.com wrote:

 Well, the Debian version of fsodeviced seems not to work
 straightforwardly yet.  It dates from 10th Jan and appears not to
 provide the GetPower method of org.freesmartphone.Device.PowerControl,

Actually the problem here was that there's now no PowerControl path
for usb.  I think this makes sense, because the USB can't be powered
on and off in an analogous way to GSM, Wifi, GPS and Bluetooth.  So I
guess it was just an oddity that FSO1's odeviced used to provide that
path, and a bug for openmoko-panel-plugin to use it.  o-p-p users can
work around this by unchecking usb is Active in the PanelPlugin tab
of o-p-p's config.

 and the GetInfo method of
 org.freesmartphone.Device.PowerSupply.

The problem here was that

  self.batteryPath = '/org/freesmartphone/Device/PowerSupply/battery'

is wrong now.  It should be

  self.batteryPath = '/org/freesmartphone/Device/PowerSupply/0'

o-p-p users can make this change in panelplugin/BatteryIcon.py.

I should say, though, that I still don't have complete battery
reporting with fsodeviced + o-p-p; I'll write again once I have that.
This change just stops o-p-p from trying its initialization loop over
and over again.

 Also, FWIW, with fsodeviced instead of odeviced, and with
 notification-daemon installed, I get lots of spurious notification
 popups about resource state changes (when nothing is really changing).

This was a consequence of either or both of the above.  o-p-p kept
failing its initialization, so retrying, failing, retrying, etc.

 So, I'm going back to odeviced for now, but will try fsodeviced again
 after it's been updated.

I'm now using fsodeviced again and planning to stick with it (as part
of trying to make sure I'm using up to date kernel and modern stuff).
There's a bit more to do (in o-p-p) to get the battery reporting
right, but everything else looks fine.

Regards,
Neil

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [PATCH] frameworkd battery status reporting

2010-02-27 Thread Michael 'Mickey' Lauer
Hi Neil,

can you point me to an example why this patch is necessary?

On a related note, I think this code path is not in use since we moved
to fsodeviced.

-- 
:M:


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [PATCH] frameworkd battery status reporting

2010-02-27 Thread Neil Jerram
On 27 February 2010 12:29, Michael 'Mickey' Lauer
mic...@vanille-media.de wrote:
 Hi Neil,

Hi Mickey,

Thanks for taking a look at this...

 can you point me to an example why this patch is necessary?

Isn't that covered by the quoted section of my previous email?  In
summary, after installing the non-debug kernel, my
openmoko-panel-plugin no longer showed the battery charging status
correctly.

 On a related note, I think this code path is not in use since we moved
 to fsodeviced.

Ah, good, that sounds like a likely explanation for why no one else
has reported this.  I'm sure that SHR is using fsodeviced, and it may
also be the default now for new Debian installs.

So I'll try switching to fsodeviced too; if that solves the problem, I
agree that it's probably not worth changing the old Python code.

Regards,
   Neil

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [PATCH] frameworkd battery status reporting

2010-02-27 Thread Neil Jerram
On 27 February 2010 19:04, Neil Jerram neiljer...@googlemail.com wrote:

 So I'll try switching to fsodeviced too; if that solves the problem, I
 agree that it's probably not worth changing the old Python code.

Well, the Debian version of fsodeviced seems not to work
straightforwardly yet.  It dates from 10th Jan and appears not to
provide the GetPower method of org.freesmartphone.Device.PowerControl,
and the GetInfo method of
org.freesmartphone.Device.PowerSupply.

Also, FWIW, with fsodeviced instead of odeviced, and with
notification-daemon installed, I get lots of spurious notification
popups about resource state changes (when nothing is really changing).

So, I'm going back to odeviced for now, but will try fsodeviced again
after it's been updated.

  Neil

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[PATCH] frameworkd battery status reporting

2010-02-25 Thread Neil Jerram
On 5 February 2010 22:44, Neil Jerram neiljer...@googlemail.com wrote:
 On 14 January 2010 22:41, Neil Jerram neiljer...@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...

Neil
From 14eef5a5bfc1e9d1b673fa1af050a4bb8a3118d4 Mon Sep 17 00:00:00 2001
From: Neil Jerram neiljer...@googlemail.com
Date: Fri, 5 Feb 2010 22:35:40 +
Subject: [PATCH] Fix battery status reporting with latest andy-tracking kernel

---
 framework/patterns/kobject.py |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/framework/patterns/kobject.py b/framework/patterns/kobject.py
index fec201b..adc44fa 100644
--- a/framework/patterns/kobject.py
+++ b/framework/patterns/kobject.py
@@ -108,6 +108,10 @@ class KObjectDispatcher( object ):
 
 def _addMatch( self, action, path, callback ):
 logger.debug( _addMatch %s, %s, %s % ( action, path, callback ) )
+path = os.path.realpath( /sys%s % path )
+logger.debug( real /sys path for addMatch is %s % path )
+path = path[4:]
+logger.debug( real path for addMatch is %s % path )
 #print action='%s', path='%s' % ( action, path )
 if action == '*':
 self._addMatch( add, path, callback )
-- 
1.7.0

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community