Hi Sylwester, On Wednesday 18 May 2011 17:57:37 Sylwester Nawrocki wrote: > On 05/18/2011 05:22 PM, Hans Verkuil wrote: > > > > I have experimented with control events to change ranges and while it can > > be done technically it is in practice a bit of a mess. I think personally > > it is just easier to have separate controls. > > > > We are going to have similar problems if different video inputs are > > controlled by different i2c devices with different (but partially > > overlapping) controls. So switching an input also changes the controls. I > > have experimented with this while working on control events and it became > > very messy indeed. I won't do this for the first version of control > > events. > > > > One subtle but real problem with changing control ranges on the fly is > > that it makes it next to impossible to save all control values to a file > > and restore them later. That is a desirable feature that AFAIK is > > actually in use already. > > What are your views on creating controls in subdev s_power operation ? > Some sensors/ISPs have control ranges dependant on a firmware revision. > So before creating the controls min/max/step values need to be read from > them over I2C. We chose to postpone enabling ISP's power until a > corresponding video (or subdev) device node is opened. And thus controls > are not created during driver probing, because there is no enough > information to do this. You can power the device up during probe, read the hardware/firmware version, power it down and create/initialize controls depending on the retrieved information. > I don't see a possibility for the applications to be able to access the > controls before they are created as this happens during a first device > (either video or subdev) open(). And they are destroyed only in > video/subdev device relase(). > > Do you see any potential issues with this scheme ? -- 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
