Hi! > > On 04/03/2017 09:00 PM, Bjorn Andersson wrote: > [..] > > > For the patterns I don't know how a trigger for this would look like, > > > how would setting the pattern of a trigger be propagated down to the > > > hardware? > > > > We'd need a new op and API similar to blink_set()/led_blink_set(). > > > > I've tried to find different LED circuits with some sort of pattern > generator in an attempt to figure out how to design this interface, but > turned out to be quite hard to find examples; the three I can compare > are: > > * LP5xx series "implements" pattern generation by executing code. It supports "linear" and "exponential" transitions between values. Variable number of steps. > * Qualcomm LPG iterates over 2-64 brightness-values in a pattern, at a > fixed rate with knobs to configure what happens before starting and > after finishing iterating over the defined values. It does not support > smooth transitions between values. > > * AS3676 supports a pattern of 32 values controlling if the output > should be enabled or disabled for each 32.5ms (or 250ms) time period. > The delay before repeating the pattern can be configured. It support > smooth transitions between the states. Ok, that's "really interesting" one. As far as I can see, the pattern really should only contain justtwo intensities... > So, while I think I see how you would like to architect this interface I > am not sure how to figure out the details. > > The pattern definition would have to be expressive enough to support the > features of LP5xx and direct enough to support the limited AS3676. It > would likely have to express transitions, so that the LPG could generate > intermediate steps (and we will have to adapt the resolution of the > ramps based on the other LPGs in the system). That's why I believe it is important to present whole pattern engine as one unit to the userspace. Userspace should always upload pattern for _all_ the LEDs at once. > How do we do with patterns that are implementable by the LP5xx but are > not with the LPG? Should we reject those or should we do some sort of > best-effort approach in the kernel? Up to you, I guess. Both rejecting and best-effort make some sense. OTOH if pattern is "(off, 0msec), (white, +1000msec), (off, +0msec)"... you can't really do it "exactly" even on LP5xx, due to non-trivial conversion between PWM and what user sees.... So on LPG you'd really do "(off, 0msec), (10% white, +100msec), (20% white, +100msec), ..." AS3676... I guess after we reject all patterns that have more than 0 and one specific brightness, we can use similar approximation we'd do on LPG? > > This is what we have now, so we can live with it. Addition of a new > > RGB trigger would be an improvement of the existing state. > > > > If we do the brightness compensation (for e.g. white balance > adjustments) in a trigger then there's added value. > > The part where I see this affects the LPG driver is that the brightness > of the patterns might have to be adjusted accordingly - which probably > would be easier to implement if the kernel just exposed the compensation > values to user space. Well, compensation needs to happen "during the transitions", too. 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
