On Sunday 08 June 2008 23:27:23 Sean McNeil wrote: > 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.
Given that there is a charging trigger since ages in the kernel LED class, it looks like adjusting this to get Will's behaviour is a sane path. :M:
