Hi Hans, Repurposing the mail thread, trimming the CC list, and adding a few people who I expect to be interested in the new topic. On Wed, Dec 04, 2024 at 11:02:07AM +0200, Laurent Pinchart wrote: > On Wed, Dec 04, 2024 at 08:59:04AM +0100, Hans Verkuil wrote: > > On 03/12/2024 18:18, Laurent Pinchart wrote: [snip] > > > My experience with the V4L2 control API is that we've overdesigned quite > > > a few things, and in particular control events. The independent > > > "capture" and "control panel" application model that V4L2 controls were > > > designed for is not really a good fit for the 21st century anymore. The > > > V4L2 API isn't rich enough to arbitrate between applications that are > > > not designed to collaborate, and way too rich when applications do > > > collaborate. The only two real use cases I found for control events are > > > async set completion notification, and notification of automatic changes > > > to other controls (and in particular changes to control limits) when a > > > control is set. The second use case isn't even something that we support > > > well today: to make it really usable, the change notification should be > > > *synchronous* with the control set ioctl, returning the information from > > > the same ioctl, not through asynchronous control events. [snip] > > Regarding the second use case: it's perfectly doable, but it would require a > > new ioctl. You would need really good arguments for doing that. > > I'm not sure I'd consider it doable. To make this trully useful we would > need to also report the value of changed controls (including limits) > from a S_FMT or S_SELECTION call. Yes, it could be achieved, but the > cost of doing so is probably not worth it. There's another change that would hopefully be simpler (but not simple), and would bring important improvements. Controls and subdev format/selection rectangles use a very different try model: the former use a TRY ioctl, while the latter use a TRY context. The TRY context makes it possible to try a full configuration of a subdev without changing its state, where the TRY ioctl can only support trying a control in isolation of all other parameters. This is blocking quite a few subdev features for which we would like to use controls, and is also problematic for existing controls (such as h/v flip or rotation, as they affect the format). Extending the control get/set ioctls with a "which" parameter shouldn't be difficult, but wiring that to the control framework is the part that scares me. To make this possible, we will need to store information about controls in the v4l2_subdev_state. I would like to minimize the amount of information stored there, and the complexity required to instantiate a new state, as that should be as lightweight as possible. To that end, we can limit the mechanism to, for instance, forbid adding new controls to a control handler after its initialization phase. Ideally, we shouldn't duplicate in the subdev state any information that can't change, such as the type of a control. Only the current value and the limits should be stored there. We will also need to be careful about locking. This mechanism should protect access to control information using a state-level lock and not locks embedded deep in the control framework, as we would then suffer from AB-BA deadlock issues. This new mechanism would be primarily used for subdevs in a first step, but it should be implemented in such a way to also be usable for video devices. Now, the real question: how can we make this happen ? :-) -- Regards, Laurent Pinchart
