On Fri 07 Apr 06:32 PDT 2017, Pavel Machek 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? > > Well... I'm not sure if we _want_ to do triggers for > patterns. LED triggers change rather quickly (100 times a second?) so > doing them in kernel makes sense. Patterns take 10s of seconds, so we > do not need to handle them in kernel. > On any current Qualcomm based phone (using the Qualcomm PMIC to drive the RGB notification LED) the patterns are hard coded in DeviceTree and the option you have in runtime is to enable/disable the usage of the configured pattern and a few knobs of how to traverse the configured pattern. When you enter e.g. a low-battery scenario you trigger the red LED to run its low-battery-pattern and you don't touch it until there's a higher prio notification (e.g. someone connects the charger). So in the current implementation patterns "never" changes and they are triggered only every time you get some event/notification. A benefit of not using triggers for patterns is that I can assign patterns to triggered events, e.g. I can configure my LEDs to flash & fade out when some trigger happens. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
