Re: [PATCH] Illuminators and status LED controls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2010-09-08 at 15:27 -0400, Alex Deucher wrote:
> On Wed, Sep 8, 2010 at 2:58 PM, Peter Korsgaard <jacmet@xxxxxxxxxx> wrote:
> >>>>>> "Andy" == Andy Walls <awalls@xxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux