Hi Mauro, On Monday 13 September 2010 16:38:03 Mauro Carvalho Chehab wrote: > Em 13-09-2010 10:49, Andy Walls escreveu: > > 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: > >>>> 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@xxxxxxxxx> 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. > > This doesn't seem to be a good reason. Keeping a LED after its usage is > annoying to the user, can cause damage on devices (reduce lifetime) and > can draw lots of power from the batteries (on battery-powered devices). > > > For a USB connected device, turning off the illuminator after the fact > > is simple, if the user has no other recourse: unplug the device. :) > > Try to unplug the flash led on your cell phone ;) Flash are much more complex than "simple" illuminators. They require pre-flash timing information and flash current for instance. The flash API will need a control to set the flash duration, and the driver (or hardware) should turn the flash off automatically after a security timeout (depending on the current, the hardware, ...). > >> 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) > > True, but it may have an alternative syntax for it, like: > > v4l2-ctl -d /dev/video0 -c illuminator_2=1 --run cheese [<args>] > > This way, if cheese or v4l2-ctl abends, the illuminator will be turned off. > > Of course, we'll likely need to have a flag visible on userspace, to say > that such control resets to an "off" state when the application dies, to > avoid someone to use it like: > v4l2-ctl -d /dev/video0 -c illuminator_2=1 -- 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
