Laurent,
Thanks for the quick feedback. See my comments below:
On 11/23/2010 04:45 PM, Laurent Pinchart wrote:
On Tuesday 23 November 2010 23:29:10 Lane Brooks wrote:Laurent,
If the links are setup to the resizer, then it seems that user space
applications should be able to talk the resizer output (/dev/video3)
like a traditional V4L2 device and need not worry about the new media
framework. It even seems possible for the resizer to allow the final
link format to be adjusted so that the user space application can
actually adjust the resizer subdev output format across the range of
valid resizer options based on the format of the resizer input pad. If
the resizer output device node worked this way, then our camera would
work with all the existing V4L2 applications with the simple caveat that
the user has to run a separate setup application first.
The resizer output device node does not currently behave this way, and I
am not sure why. These are the reasons that I can think of as to why:
1. It has not been implemented this way yet.
2. I am doing something incorrectly with the media-ctl application.
3. It not intended to work this way (by the new media framework design
principles).
4. It cannot work this way because of some reason I am not considering.
It's probably a combination of 1 and "it cannot work this way because of
reasons I can't remember at 1AM" :-)
The ISP video device nodes implementation doesn't initialize vfh->format when
the device node is opened. I think this should be fixed by querying to
connected subdevice for its current format. Of course there could be no
connected subdevice when the video device node is opened, in which case the
format can't be initialized. Pure V4L2 applications must not try to use the
video device nodes before the pipeline is initialized.
I'll look into implementing this. This is mostly what I am looking for
and hopefully won't be too involved to implement.
Regarding adjusting the format at the output of the connected subdevice when
the video device node format is set, that might be possible to implement, but
we will run into several issues. One of them is that applications currently
can open the video device nodes, set the format and request buffers without
influencing the ISP at all. The format set on the video device node will be
checked against the format on the connected pad at streamon time. This allows
preallocating buffers for snapshot capture to lower snapshot latency. Making
set_format configure the connected subdev directly would break this
How does calling set_format on the subdev pad at the same as the device
node prevent preallocating buffers? I don't really understand the ISP
buffering, so I think at this point I will look into implementing the
previous option and then perhaps I will have a better understanding of
the issue you raise here. I think it is only the resizer that would need
this capability. I am bringing it up as a nice to have, but we can
certainly live without it if it does not fit into the design goals of
the framework.
Lane
--
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
