Hi Laurent! On 11/29/2011 07:10 PM, Laurent Pinchart wrote: > Hi Sylwester, > > On Tuesday 29 November 2011 17:40:10 Sylwester Nawrocki wrote: >> On 11/29/2011 12:08 PM, Hans Verkuil wrote: >>> On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote: >>>> On 11/28/2011 01:39 PM, Hans Verkuil wrote: >>>>> On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: >>>>>> On 11/28/2011 12:38 PM, Hans Verkuil wrote: >>>>>>> On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: >> >> Nevertheless I have at least two use cases, for the alpha control and >> for the image sensor driver. In case of the camera sensor, different device >> revisions may have different step and maximum value for some controls, >> depending on firmware. >> By using v4l2_ctrl_range_update() I don't need to invoke lengthy sensor >> start-up procedure just to find out properties of some controls. > > Wouldn't it be confusing for applications to start with a range and have it > updated at runtime ? > Indeed, changing a control range like this is not the brightest idea ever. I would not consider doing something like this commonly. However if the applications are aware that the control range may change at any time and they handle the events, there shouldn't be a problem. Of course life for applications is getting harder. The complexity for applications is increasing maybe a bit too much at this point already... I guess you would agree that it's best to power up the sensor when sub-device node is opened and do all necessary setup before any subdev file operation is commenced. For that I'm just looking forward for the common struct clk to be merged and all platforms to be converted to it. So we can use a struct clk object to enable sensor clock from subdev drivers level. -- Regards, Sylwester -- 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
