On Monday, May 02, 2011 18:04:18 Sakari Ailus wrote: > Sakari Ailus wrote: > > Laurent Pinchart wrote: > >> Hi Sakari, > > > > Hi Laurent, > > Hi Hans and Laurent, > > >> On Tuesday 29 March 2011 13:51:38 Sakari Ailus wrote: > >>> Sakari Ailus wrote: > >>>> Hans Verkuil wrote: > >>>>> On Tuesday, March 29, 2011 11:35:19 Sakari Ailus wrote: > >>>>>> Hi Hans, > >>>>>> > >>>>>> Many thanks for the comments! > >>>> > >>>> ... > >>>> > >>>>>> It occurred to me that an application might want to turn off a flash > >>>>>> which has been strobed on software. That can't be done on a single > >>>>>> button control. > >>>>>> > >>>>>> V4L2_CID_FLASH_SHUTDOWN? > >>>>>> > >>>>>> The application would know the flash strobe is ongoing before it > >>>>>> receives a timeout fault. I somehow feel that there should be a control > >>>>>> telling that directly. > >>>>>> > >>>>>> What about using a bool control for the strobe? > >>>>> > >>>>> It depends: is the strobe signal just a pulse that kicks off the flash, > >>>>> or is it active throughout the flash duration? In the latter case a > >>>>> bool makes sense, in the first case an extra button control makes > >>>>> sense. > >>>> > >>>> I like buttons since I associate them with action (like strobing) but on > >>>> the other hand buttons don't allow querying the current state. On the > >>>> other hand, the current state isn't always determinable, e.g. in the > >>>> absence of the interrupt line from the flash controller interrupt pin > >>>> (e.g. N900!). > >>> > >>> Oh, I need to take my words back a bit. > >>> > >>> There indeed is a way to get the on/off status for the flash, but that > >>> involves I2C register access --- when you read the fault registers, you > >>> do get the state, even if the interrupt linke is missing from the > >>> device. At least I can't see why this wouldn't work, at least on this > >>> particular chip. > >>> > >>> What you can't have in this case is the event. > >>> > >>> So, in my opinion this suggests that a single boolean control is the way > >>> to go. > >> > >> Why would an application want to turn off a flash that has been strobbed in > >> software ? Applications should set the flash duration and then strobe it. > > > > The applications won't know beforehand the exact timing of the exposure > > of the frames on the sensor and the latencies of the operating system > > possibly affected by other processes running on the system. Thus it's > > impossible to know exactly how long flash strobe (on software, that is!) > > is required. > > > > So, as far as I see there should be a way to turn the flash off and the > > timeout would mostly function as a safeguard. This is likely dependent > > on the flash controller as well. > > Today I was working on the ADP1653 driver and realised that this chip > doesn't actually provide a way to stop the strobe by the user at all. > There's just the timeout. The user may not turn off the strobe, as it > first seemed to me in the spec. If I look at the AS3654A spec, it's > almost equally vague on this topic. > > This means that there are chips that do not allow explicitly stopping > the strobe and probably those that do (I assume that hardware people > will learn some day that a hard timeout isn't the best you can provide > to software!). > > There was a discussion on the type of the V4L2_CID_FLASH_STROBE control; > whether that should be a button or boolean control. Buttons cannot be > unpressed, so a button control would work for adp1653 but possibly not > for other similar chips in the future. > > Even if we have a standard control, can the type of the control change, > depending on the properties of the hardware? This would also allow > providing to user the knowledge on whether the flash may be explicitly > turned off. On the other hand, I don't like the idea of having a > standard control with several possible types (there are none at the > moment, AFAIK). I would side with keeping the type of the control > boolean all the time but I'm not fully certain. > > Hans, do you have an opinion on this? Theoretically the type may change depending on the hardware, but I don't think that is something we should support. In particularly, that will make it very hard to programmatically use such controls. There are all sorts of subtle problems you run into when you allow for different types for the same standard control. Regards, Hans -- 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
