On Wed, 08 Sep 2010 20:58:18 +0200 Peter Korsgaard <jacmet@xxxxxxxxxx> wrote: > >>>>> "Andy" == Andy Walls <awalls@xxxxxxxxxxxxxxxx> writes: > Andy> Incandescent and Halogen lamps that effect an image coming > Andy> into a camera are *not* LEDs that blink or flash automatically > Andy> based on driver or system trigger events. They are components > Andy> of a video capture system with which a human attempts to > Andy> adjust the appearance of an image of a subject by changing the > Andy> subject's environment. These illuminators are not some > Andy> generically connected device, but controlled by GPIO's on the > Andy> camera's bridge or sensor chip itself. Such an illuminator > Andy> will essentially be used only in conjunction with the camera. > > Agreed. > > Andy> Status LEDs integrated into webcam devices that are not > Andy> generically connected devices but controlled with GPIOs on the > Andy> camera's bridge or sensor chip will also essentially be used > Andy> only in conjunction with the camera. > > Or for any other usage the user envision - E.G. I could imagine using > the status led of the webcam in my macbook for hard disk or wifi > activity. I'm sure other people can come up with more creative use > cases as well. > > Andy> Turning these sorts camera specific illuminators and LEDs on > Andy> an off should be as simple to implement for an application > Andy> developer as it is to grasp the concept of turning a light > Andy> bulb on and off. > > The point is that the logic rarely needs to be in the v4l > applications. The status LEDs should by default go on when the v4l > device is active and go off again when not like it used to do. A v4l > application developer would normally not want to worry about such > things, and only care about the video data. > > But if a user wants something special / non-standard, then it's just a > matter of changing LED trigger in /sys/class/leds/.. [snip] > Again, for status LEDs I don't see any reason why a standard v4l tool > would care. As I mentioned above, illuminators are a different story > (comparable to a gain setting imho). [snip] > Again, I see the sysfs LED interface for status LEDs as more of a > user/administrator interface than a programming API. Hi, If I may resume this exchange: - the (microscope or device dependant) illuminators may be controlled by v4l2, - the status LED should be controlled by the LED interface. Does everybody agree? Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
