On Tue, 2010-03-09 at 12:27 +0100, Laurent Pinchart wrote: > Hi Màrton, > > Thanks for the patch. > > On Wednesday 03 March 2010 00:42:23 Németh Márton wrote: > > From: Márton Németh <nm127@xxxxxxxxxxx> > > > > On some webcams one or more LEDs can be found. One type of these LEDs > > are feedback LEDs: they usually shows the state of streaming mode. > > The LED can be programmed to constantly switched off state (e.g. for > > power saving reasons, preview mode) or on state (e.g. the application > > shows motion detection or "on-air"). > > > > The second type of LEDs are used to create enough light for the sensor > > for example visible or in infra-red light. > > > > Both type of these LEDs can be handled using the LEDs subsystem. This > > patch add support to connect a gspca based driver to the LEDs subsystem. > > They can indeed, but I'm not sure if the LEDs subsystem was designed for that > kind of use cases. The LED subsystem was designed to support LED lights and the above scenarios can certainly fit that. It provides a nice system where default use cases should just work (power light on a laptop) but the system has the control to override than and do other interesting things with it if it so wishes. > The LED framework was developed to handle LEDs found in embedded systems > (usually connected to GPIOs) that needed to be connected to software triggers > or controlled by drivers and/or specific userspace applications. Its used by many laptops so its not just embedded systems. > Webcam LEDs > seem a bit out of scope to me, especially the "light" LED that might be better > handled by a V4L2 set of controls (we're currently missing controls for camera > flashes, be they LEDs or Xenon based). > > I'll let Richard speak on this. I'm not going to push one way or another and its up to individual subsystems to way up the benefits and drawbacks and make their decision. There is nothing in the design of the system which would stop it working or being used in this case though. If the susystsme needs improvements to work well, I'm happy to accept patches too. Cheers, Richard -- 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
