On Thu, 2011-03-03 at 15:04 +0100, Laurent Pinchart wrote: > The LED API is too limited. We need to program flash time, pre-flash time, > current limits, report overheat/overcurrent events, ... See > http://www.analog.com/static/imported-files/data_sheets/ADP1653.pdf for an > example of the features found in LED flash controllers. OK. Thanks. Since, I have unwittingly managed to get myself into the position of Devil's Advocate for the LED API, I should mention that a driver can add whatever custom sysfs nodes it needs to the LED's sysfs directory, for various parameter settings and controls. Using those driver-custom sysfs nodes can lead to significant variation in how applications must control LEDs exported via the LED API by various drivers. If *all* drivers in the kernel providing an LED API don't have a common convention for controlling flash LED's, then you have a problem analogous to the problem with driver-private V4L2 controls. To clarify my position, I don't like the LED API being used in conjunction with video capture applications. The LED API is too open-ended and more suited for twiddling LEDs with scripts, than for use with general video capture or camera applications. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
