Hi Laurent,
On 07/27/2012 01:32 AM, Laurent Pinchart wrote:
Hi Michael,
On Thursday 26 July 2012 16:22:17 Michael Jones wrote:
On 07/26/2012 04:05 PM, Laurent Pinchart wrote:
On Thursday 26 July 2012 13:59:54 Michael Jones wrote:
Hello,
I would like to (re)submit a couple of patches to support V4L2 behavior
at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they
require some discussion first.
Indeed.
The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it does
today is to hack around a restriction in the V4L2 API. We needed a way to
preallocate and possibly prequeue buffers for snapshot, which wasn't
possible in a standard-compliant way back then.
The situation has since changed, and we now have the VIDIOC_CREATE_BUFS
and VIDIOC_PREPARE_BUF ioctls. My plan is to
- port the OMAP3 ISP driver to videobuf2
- implement support for CREATE_BUFS and PREPARE_BUF
- fix the G_FMT/S_FMT/ENUM_FMT behaviour
What will the G_FMT/S_FMT/ENUM_FMT behavior be then? Can you contrast
it with the behavior of my patches? If the behavior will be the same
for user space, and your proposed changes won't be in very soon, can we
use my patches until you make your changes?
At the moment the driver accepts any format you give it in a S_FMT call,
regardless of the format of the connected pad. The reason for that is to allow
VIDIOC_REQBUFS to allocate buffers for an arbitrary size.
With CREATE_BUFS and PREPARE_BUFS support, G_FMT, S_FMT and ENUM_FMT should
return the format of the connected pad.
OK, so this sounds like the same behavior I'd like to add before
CREATE_BUFS and PREPARE_BUFS support is in. My other question was if
this is the case, can we use my approach until your planned changes are in?
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
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
