Hi! > >>>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. > > But that does not allow selecting the frequency of blinking / glowing > and the hw can do the exact same thing in no-trigger / manual mode > and it would be preferable to have a single code path for setting > the pattern independent of turning the pattern on/off being under > manual or hw control. Why not? Normal triggers can have parameters, these new hw_* triggers can have parameters, too, with same semantics. But... yes, it will mean some work if you really need to support all the functionality, and I do think that it should be ok to just support a limited subset. (probably hw_on_when_charging" and "hw_glows_when_charging" with fixed parameters). Best regards, 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
