Hi Laurent, My apologies that this reply is so late, but I knew I had to sit down and think carefully about this and I didn't have time for that until today. I've decided not to quote your post but instead restate the problem in my own words. Seen abstractly you have an entity with inputs, outputs and a processing pipeline that transforms the input(s) to the output(s) somehow. And each stage of that pipeline has its own configuration. You want to provide the developer that sets up such an entity with a systematic and well-defined procedure while at the same time you want to keep the entity's code as simple as possible. Part of this procedure is already decided: you always start with defining the inputs. The confusion begins with how to setup the configuration and the outputs. I think the only reasonably way is to configure the pipeline stages in strict order from the input to the output. So you start with defining the inputs. For a scaler the next thing to set is the crop rectangle. And then finally the output. At each stage the entity will only check if the configuration parameters can work with the input. It may make the rest of the pipeline invalid, but that's OK for now. The final step comes when the output is defined. If that returns OK, then you know the whole pipeline is valid. So what to do when you have an input and an output configured and someone suddenly changes the crop configuration to a value that doesn't work with that input/output combinations? The two options I've seen are: 1) modify the crop configuration to fit the output 2) modify the output configuration to fit the crop But there is a third option which I think works much better: 3) accept the crop configuration if it fits the input, but report back to the caller that it invalidates the output. What the entity does with this crop configuration is purely up to the entity: it can just store it in a shadow configuration and wait with applying it to the hardware until it receives a consistent output format, or it can modify the output format to fit the crop configuration. In any case, if changes are made, then they should be made 'upstream'. This makes the behavior consistent. As long as you work your way from input to output, you know that any configuration you've set for earlier stages stay put and won't change unexpectedly. And if you decide to change a 'mid-pipeline' configuration, then you will get a status back that tells you whether or not you broke the upstream configuration. The advantage is that at any stage the driver code just has to check whether the new configuration is valid given the input (in which case the call will succeed) and whether the new configuration is valid for the current output and report that in a status field. Note that 'input' and 'output' do not necessarily refer to pads, it may also refer to stages of a pipeline. And the same principle should hold for both the subdev API and for the 'main' V4L API (more about that later). A suggested alternative was to do the configuration atomically. I do not think that is a good idea because it is so very hard to do things atomically. It is hard to use and it is hard to implement. The extended controls API for example has been defined years ago and there are very few drivers that implement it (let alone implement it correctly). It took the creation of the control framework (almost 2000 lines of code) to make it possible to implement it easily in drivers and I've just started out converting all drivers to this framework. And this is just for simple controls... So this sounds simple, but in practice I think it will be a disaster. I like to cut things up in small pieces, and working your way through a pipeline as proposed makes each part much easier. Since the subdev API is not yet set in stone it shouldn't be hard to provide such feedback. For the existing V4L2 API it can be a bit harder: VIDIOC_S_FMT: struct v4l2_pix_format has a priv field which I believe is never used. So we might hijack that as a flags field instead. VIDIOC_S_CROP: Can't do anything with that. However, we could define a TRY_CROP that does give back the information (i.e. 'if you try this crop rectangle, then the upstream pipeline will become invalid'). Not ideal, but it should work. ROTATE control: two options: either use one of the top bits in the control ID field (the top four bits are reserved as flags, one of them is the NEXT_CTRL flag). Or change the reserved2 field to a flags field. VIDIOC_S_STD: Can't be done. VIDIOC_S_INPUT: Can't be done. VIDIOC_S_OUTPUT: Can't be done. For these three you might be able to store some sort of information in their ENUM counterparts. VIDIOC_S_DV_PRESET: easy to add. VIDIOC_S_DV_TIMINGS: easy to add. VIDIOC_S_AUDIO/VIDIOC_S_AUDOUT: easy to add, but not sure if it is needed. I'm sure there are a lot of details to sort out if we apply this principle as well to the V4L2 API, but I think that for subdevs this should be a decent way of doing things. Unless of course I've forgotten about all sorts of subtleties that I didn't take into account. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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
