On Wed, 08 Sep 2010 20:58:18 +0200
Peter Korsgaard <jac...@sunsite.dk> wrote:
> >>>>> "Andy" == Andy Walls <awa...@md.metrocast.net> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
