On Wed, 2010-09-08 at 15:27 -0400, Alex Deucher wrote:
> On Wed, Sep 8, 2010 at 2:58 PM, Peter Korsgaard <[email protected]> wrote:
> >>>>>> "Andy" == Andy Walls <[email protected]> writes:
> >
> > Hi,
> >
> > Andy> Incandescent and Halogen lamps that effect an image coming into a
> > Andy> camera are *not* LEDs that blink or flash automatically based on
> > Andy> driver or system trigger events. They are components of a video
> > Andy> capture system with which a human attempts to adjust the
> > Andy> appearance of an image of a subject by changing the subject's
> > Andy> environment. These illuminators are not some generically
> > Andy> connected device, but controlled by GPIO's on the camera's bridge
> > Andy> or sensor chip itself. Such an illuminator will essentially be
> > Andy> used only in conjunction with the camera.
> >
> > Agreed.
> >
> > Andy> Status LEDs integrated into webcam devices that are not generically
> > Andy> connected devices but controlled with GPIOs on the camera's bridge or
> > Andy> sensor chip will also essentially be used only in conjunction with
> > the
> > Andy> 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 an off
> > Andy> should be as simple to implement for an application developer as it
> > is
> > Andy> to grasp the concept of turning a light 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/..
>
> I agree with Peter here. I don't see why a video app would care about
> blinking an LED while capturing. I suspect most apps won't bother to
> implement it, or it will be a card specific mess (depending on what
> the hw actually provides). Shouldn't the driver just turn it on or
> blink it when capturing is active or whatever. Why should apps care?
> Plus, each app may implement some different behavior or some may not
> implement it at all which will further confuse users.
>
> Alex
Hi all,
I just got finished a prototype implementation of using the LED API for
the illuminators on the QX3 microscope, so I could learn about the
interface. (No devices in any of my systems presented an led interface,
so I had.) I'm too tired right now to discuss what I've found, but I'll
hopefully respond with my observations around noon EDT tomorrow.
Two patches - my previous one using the V4L2 control API, and this
second one using the LED API - can be found as the last two patches
here:
http://linuxtv.org/hg/~awalls/qx3/
$ diffstat qx3-lamp.diff
cpia1.c | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 62 insertions(+), 11 deletions(-)
$ diffstat qx3-ledapi.diff
cpia1.c | 185 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 183 insertions(+), 2 deletions(-)
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
