Re: [PATCH] Illuminators and status LED controls

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

 



Hi Alex,

On Wednesday 08 September 2010 21:27:19 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?

The main reason I know about to allow applications to turn the status LED off 
is to avoid reflections on glasses.

> Plus, each app may implement some different behavior or some may not
> implement it at all which will further confuse users.

-- 
Regards,

Laurent Pinchart
--
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