Hi Hans, Hans Verkuil wrote: [clip] >> Should't v4l2_ctrl_new_std take a control type as well ? > > The type is set automatically as that is determined by the control ID. > >> What about hardware for which the boundaries are only known at runtime, or >> could depend on the values of other controls ? I'm thinking about UVC devices >> for instance, the boundaries, step and default values need to be retrieved >> from the hardware. I currently do that at runtime when the control is queried >> for the first time and cache the values, as doing it during initialization >> (probe function) crashes a few webcams. That doesn't seem to be possible with >> the control framework. > > It is possible to add controls to an existing control handler at runtime. > It is also possible to change boundaries at runtime: you just change the > relevant values in v4l2_ctrl. There is no function for that, it's enough > to call v4l2_ctrl_lock(), change the values and call unlock(). > > I could make a function that does this, but UVC is the only driver that I > know of that might need this. It won't be for long. Think of the sensor drivers, for example. The maximum exposure time (often expressed in lines) is dependent on the active sensor area (lines) plus vertical blanking. I'd assume the active area to be selected in other ways than using controls, however. The vertical blanking, though, also affects the frame rate, and thus available exposure time. Not quite sure whether the user should be left to touch the vertical blanking directly. Regards, -- Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx -- 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
