Hi! > >Ok, so it seems we need "hardware_trigger" (or "hw_trigger"?) file, > >anyway, because it is common for hardware to have few modes. > > > >What about getting rid of hardware_controlled file, and just having > >"hw_trigger", working similar to current "trigger" semantics? > > > >hw_trigger would > > > >* only be present if LED can be hardware controlled > > > >* echo none > hw_trigger would give control to software > > > >* echo mode > hw_trigger would give control to hardware, in given mode > > > >* cat hw_trigger would list possible modes. > > > >* echo 0 > brightness would clear set both "trigger" and "hw_trigger" to > > none. > > > >* any change to trigger or hw_trigger would set the other one to > > "none". > > > >But .. looking at proposal. I believe most consistent / logical > >solution would be to simply add hardware triggers into list of > >triggers, and treat them the same way. Yes, that would mean different > >trigger lists per LED, but I don't think that's a problem, and it is > >logical solution for our users. > > OK, so we would have say a hw_battery_is_charging trigger for the PMIC > led driver we were discussing recently, and selecting this buts the > LED under hw control but this hw-trigger just turns the LED on and off. > The device also has a hw_pattern (on / blink / glow) which selects what > it shows when "triggered" (or manually turned on). > I assume this would then use a hw_pattern file, how do you see these > 2 interacting ? What happens when the trigger is changed, does the > pattern then gets reset ? etc. Actually, thinking about that again, in your case I'd just present three triggers "hw_on_when_charging", "hw_blinks_when_charging" and "hw_glows_when_charging"... if we really need to support all the functionality. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
