Andy Green wrote:
Somebody in the thread at some point said:
| 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?
I never used LED Class before now, I see it's pretty cool and the
triggers are not hard to register and make events on. So thanks for the
good idea.
I will add support for it to my patch, with the LED trigger about
charging owned by pcf50633.c, which "owns the charger".
That would be great.
| 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.
There are three issues here.
~ - Capture anywhere of charging state
Whatever information you were bringing out, did it really include
charging state -- as opposed to charger presence? AFAIK no event source
existed for stopping and resuming charging until my patch. Did you
really solve that already?
No, I didn't really solve it. I had some of the framework there,
however, which could have given the charging state correctly from the
apm emulation.
~ - Exposure of events
Holger has this stuff coming out of "change notification" uevents
associated with the battery kobject, it sounds OK to me as a general
solution userspace can subscribe to. Probably better than sticking
events down the PMU input event subsystem for example, which would have
been defensible seeing as we do it already for some PMU things.
This is what I need as well. I also need uevents for when the capacity
or temperature changes. I hope the uevents aren't being initiated with
the kobjects directly. They should be calling into a hook for the
battery device and then it should in turn be calling
power_supply_changed(). I would also very much like to see the
power_supply class have 3 objects: battery (instead of bat as it is more
standard), ac, and usb. This is what I have now and tried to indicate
charging state through the ac and usb objects. By the way, I've found
that some of the timing and retries for reading battery info are too
low. I'd get errors trying to read the status if I did it too often.
~ - Lighting LEDs or reacting otherwise; and overloading for notifications
I never heard about even the need for shared formal UI notifications on
LEDs until after the charging patch. So that is at least one reason why
we don't get to the end in one step.
This has been a little bit of a sticky issue. I firmly believe that the
kernel should not dictate LED behavior. If we can implement the charging
state stuff as an LED trigger which can be optionally turned on or off
(I'm somewhat OK with it being a default trigger, but perhaps it can be
a config option?), then I'm happy.
-Andy
