reading config parameters of omap3-isp subdevs
Hi all,
I am playing around with some parameters in the previewer on the ISP. With ioctl VIDIOC_OMAP3ISP_PRV_CFG I am able to write the various parameters but what I'm missing is a way to read them. For example, I have no way to adjust only coef2 in 'struct omap3isp_prev_wbal' while leaving the others unchanged. If I could first read the whole omap3isp_prev_wbal structure, then I could change just the things I want to change. This seems like it would be common functionality for such ioctls. I didn't find any previous discussion related to this.
I could imagine either adding a r/w flag to 'struct omap3isp_prev_update_config' or adding a new ioctl entirely. I think I would prefer the r/w flag. Feedback?
I noticed that other ISP subdevs have similar ioctls. Perhaps a similar thing would be useful there, but right now I'm only looking at the previewer.
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
Hi Michael,
Quoted 11 lines · On Friday 16 March 2012 15:06:15 Michael Jones wrote:
Hi all,
I am playing around with some parameters in the previewer on the ISP. With ioctl
VIDIOC_OMAP3ISP_PRV_CFGI am able to write the various parameters but what I'm missing is a way to read them. For example, I have no way to adjust only coef2 in 'structomap3isp_prev_wbal' while leaving the others unchanged. If I could first read the wholeomap3isp_prev_wbalstructure, then I could change just the things I want to change. This seems like it would be common functionality for such ioctls. I didn't find any previous discussion related to this.
Quoted 7 lines
I could imagine either adding a r/w flag to 'struct
omap3isp_prev_update_config' or adding a new ioctl entirely. I think I would prefer the r/w flag. Feedback?I noticed that other ISP subdevs have similar ioctls. Perhaps a similar thing would be useful there, but right now I'm only looking at the previewer.
Adding a R/W bit to the flag argument should indeed work. However, I'm wondering what your use case for reading parameters back is. The preview engine parameter structures seem pretty-much self-contained to me, I'm not sure it would make sense to only modify one of the parameters.
Signature · 3 lines
Regards, Laurent Pinchart
Hi Laurent,
Quoted 3 lines · Laurent Pinchart
Hi Michael,
On Friday 16 March 2012 15:06:15 Michael Jones wrote:
[snip]
Quoted 3 lines
Adding a R/W bit to the flag argument should indeed work. However, I'm wondering what your use case for reading parameters back is.
The simplest use case in my mind is that after the user has fiddled around with config parameters, they should be able to set them back to their original state. For that, they need to know what the original state was.
Quoted 3 lines
The preview
engine parameter structures seem pretty-much self-contained to me, I'm not sure it would make sense to only modify one of the parameters.
Why doesn't it make sense to write to only e.g. 'COEF3' in the PRV_WBGAIN register? Especially considering the sparse documentation of many of these registers, I would like to be able to tweak the existing parameters from their defaults, rather than start from scratch.
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
Hi Michael,
Quoted 11 lines · On Tuesday 20 March 2012 11:06:56 Michael Jones wrote:
Quoted 1 line · Laurent Pinchart
On Friday 16 March 2012 15:06:15 Michael Jones wrote:
[snip]
Quoted 2 lines
Adding a R/W bit to the flag argument should indeed work. However, I'm wondering what your use case for reading parameters back is.
The simplest use case in my mind is that after the user has fiddled around with config parameters, they should be able to set them back to their original state. For that, they need to know what the original state was.
Quoted 7 lines
Quoted 2 lines
The preview engine parameter structures seem pretty-much self-contained to me, I'm not sure it would make sense to only modify one of the parameters.
Why doesn't it make sense to write to only e.g. 'COEF3' in the
PRV_WBGAINregister? Especially considering the sparse documentation of many of these registers, I would like to be able to tweak the existing parameters from their defaults, rather than start from scratch.
Because configuring white balance requires modifying all the coefficients.
I agree that querying the default parameters can be useful for experimentation purpose, although in that case you could just have a look at the driver source code ;-) I've sent a patch that modifies the way the preview engine handles the configuration process to the linux-media mailing list. I could try implementing read access on top of that, but I'm not sure when I'll have time to do so. If you want to give it a try, I'll review your code :-) Be careful of the race conditions, they're not trivial.
Signature · 3 lines
Regards, Laurent Pinchart