[PATCH 0/5] Power supply and resume ordering meddling

[Sean McNeil]

Hi Andy,

I'm curious... there is a control state for LEDs where you can set the 
trigger. Why can't that be implemented properly so that if someone wants 
the LED to reflect charging state then they just write the appropriate 
trigger to that LED? If not, then it can be set to something else (i.e. 
for me, timer). Wouldn't that satisfy everyone?

As far as exposing the charging stuff, I provided a patch quite some 
time ago that brought out the information as power_supply class objects. 
I was using information from the apm emulation, but it could be changed. 
This is really where Linux is suppose to be exposing such information.

Andy Green wrote:
> 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.
>
> -Andy