Re: [PATCH] Illuminators and status LED controls

[Andy Walls <awalls@md.metrocast.net>]

On Mon, 2010-09-13 at 08:45 -0300, Mauro Carvalho Chehab wrote:
> Em 13-09-2010 05:06, Hans Verkuil escreveu:
> > On Monday, September 13, 2010 09:04:18 Laurent Pinchart wrote:
> >> Hi Hans,
> >>
> >> On Thursday 09 September 2010 13:48:58 Hans de Goede wrote:
> >>> On 09/09/2010 03:29 PM, Hans Verkuil wrote:
> >>>>> On 09/09/2010 08:55 AM, Peter Korsgaard wrote:
> >>>>>> "Hans" == Hans Verkuil<hverkuil@xs4all.nl>   writes:
> >>>>>>
> >>>>>> I originally was in favor of controlling these through v4l as well, but
> >>>>>> people made some good arguments against that. The main one being: why
> >>>>>> would you want to show these as a control? What is the end user supposed
> >>>>>> to do with them? It makes little sense.
> >>
> >> Status LEDs reflect in glasses, making annoying color dots on webcam pictures. 
> >> That's why Logitech allows to turn the status LED off on its webcams.
> > 
> > That's a really good argument. I didn't think of that one.
> 
> There's one difference between illuminators and leds and anything else that we use
> currently via CTRL interface: all other controls affects just an internal hardware
> capability that are not visible to the user, nor can cause any kind of damage or 
> annoyance.
> 
> On the other hand, a LED and an illuminator that an application may forget to turn
> off could be very annoying, and may eventually reduce the lifecycle or a device (in
> the case of non-LED illuminators, for example).

Yes, I can appreciate that.  On driver unload and suspend that should
certainly be the case for illuminators.

However, I don't think that's a good idea for final close on a file
descriptor though.  That's a departure from normal V4L2 behavior.

For a USB connected device, turning off the illuminator after the fact
is simple, if the user has no other recourse: unplug the device. :)


> So, a special treatment seems to be required for both cases: if the application that
> changed the LED or illuminator to ON dies or closes, the LED/illuminator should be
> turned off by the driver.

That will break cases like these:

$ v4l2-ctl -d /dev/video0 -c illuminator_2=1
$ (command to run app that doesn't present all controls, e.g. cheese)

Regards,
Andy

> Maybe we could add an internal flag to be consumed by the controls core, and call it
> during release() callback, to be sure that such controls will return to a default state
> (0) when users count reaches zero.
> 
> > 
> > I'm happy with a menu control for LEDs, something like:
> > 
> > Auto (default)
> > Off
> > 
> > and possibly:
> > 
> > On
> > Blink
> > 
> > Although I'm not so sure we need/want these last two.
> 
> Provided that it will return to Off (or auto) after application shuts down, I don't see
> why not offering such control to userspace. While it may not make sense on desktops,
> turning LEDs on may be interesting on some cases. For example, there are several Android
> applications to turn the webcam "flash" LED on, meant to use the cell phone as an 
> emergency light.