[PATCH 0/5] Power supply and resume ordering meddling
andy at openmoko.com
Sun Jun 8 13:09:02 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| Andy Green wrote:
|> You either need a drumbeat type pattern for each signal as I proposed in
|> another mail, or to move it to the power button.
| Hi Andy,
| Just want to make sure we are still moving.
| What is being done now?
| I don't want to make any assumptions that throw away any work to date.
On the charging feedback part: actual logical charging tracking so we
know if we are charging or not is done by my original patch.
Unfortunately everyone has their own ideas about those LEDs and felt
that they had rights over controlling them, so nobody had a good word
for driving the LED directly from the charging state (despite that's all
you asked for).
Holger is partway through a patchset that will expose events when there
is a change in charger or charging to userspace, currently it just says
about if USB power came or not, not if charging is happening.
When we combine his uevent patches with my charging patch, and somebody
is listening in userspace for the events are plugging it together with
the LED state control, we'll be back to where we were with the light
lighting up according to if we are charging or not. Except there may or
may not be less hating going on.
It means the LED behaviour is contingent on the daemon or whatever
listens to the events being up, otherwise it should be fine. The
charging LED is contingent on Linux being up anyway, probably I am in a
minority running my phones in runlevel 3 with X down.
For the notification part: the situation is impossible, Mickey says he
will fork stuff until his opinions stick anyway, you did not give any
final guidance, I am not doing anything about it since it is clearly an
"automatic loser" to go near it as it stands.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel