Re: Omap3 ISP + Gstreamer v4l2src
Hi Michael, On Wednesday 07 December 2011 12:01:17 Michael Jones wrote: On 12/07/2011 11:34 AM, Laurent Pinchart wrote: On Wednesday 07 December 2011 09:02:42 Adam Pledger wrote: Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. No worries. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, Please note that BT.656 support is still experimental, so issues are not unexpected. as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input- infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: [snip] Looks good. The following works nicely: yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2 The problem comes when I try to use gstreamer to capture from /dev/video2, using the following: gst-launch v4l2src device=/dev/video2 ! 'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv This fails with: ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed getting controls attributes on device '/dev/video2'. Additional debug info: v4l2_calls.c(267): gst_v4l2_fill_lists (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed querying control 9963776 on device '/dev/video2'. (25 - Inappropriate ioctl for device) My question is, should this just work? It was my understanding that once the pipeline was configured with media-ctl then the CCDC output pad should behave like a standard V4L2 device node. That's more or less correct. There have been a passionate debate regarding what a standard V4L2 device node is. Not all V4L2 ioctls are mandatory, and no driver implements them all. The OMAP3 ISP driver implements a very small subset of the V4L2 API, and it wasn't clear whether that still qualified as V4L2. After discussions we decided that the V4L2 specification will document profiles, with a set of required ioctls for each of them. The OMAP3 ISP implements the future video streaming profile. I'm not sure what ioctls v4l2src consider as mandatory. The above error related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented by the OMAP3 ISP driver and will likely never be. I don't think that should be considered as mandatory. I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't implemented in the OMAP3 ISP driver. That might change in the future, but I'm not sure yet whether it will. In any case, you might have to modify v4l2src and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago to this mailing list. Here was my submission for ENUM_FMT support: http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html I submitted this in order to be able to use the omap3-isp with GStreamer. I missed the discussion about V4L2 profiles, but when I submitted that patch we discussed whether ENUM_FMT was mandatory. After I pointed out that the V4L2 spec states plainly that it _is_ mandatory, I thought Laurent basically agreed that it was reasonable. Laurent, what do you think about adding ENUM_FMT support now? I'm OK with it, but we need to discuss the details. During the latest V4L2 meeting in Prague we decided to create a streaming profile for V4L2 device nodes such as the ones created by the OMAP3 ISP driver. We now need to decide which ioctls will be mandatory in that profile (ENUM_FMT will likely be), and what they should return exactly. That's on my to-do list (but handling my e- mail backlog comes first :-)). I realise that this might be something borked with my build dependencies (although I'm pretty certain that v4l2src is being built against the latest libv42) or gstreamer. Before I start digging through the code to work out what is going on with the ioctl handling, I thought I would check to see whether this should work, or whether I am doing something fundamentally silly. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Omap3 ISP + Gstreamer v4l2src
Hi Adam, On Wed, Dec 07, 2011 at 08:02:42AM +, Adam Pledger wrote: Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0x0 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Sink [SGRBG10 4096x4096] - OMAP3 ISP CCP2 input:0 [] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CCDC:0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Source - OMAP3 ISP CCP2:0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [SGRBG10 4096x4096] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CSI2a output:0 [] - OMAP3 ISP CCDC:0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink - OMAP3 ISP CSI2a:1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Sink [UYVY2X8 720x625] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 3-005d:0 [ENABLED] pad1: Source [UYVY2X8 720x625] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [UYVY2X8 720x624] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Sink - OMAP3 ISP CCDC:1 [ENABLED] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088] - OMAP3 ISP CCDC:2 [] - OMAP3 ISP preview input:0 [] pad1: Source [YUYV 4082x4088] - OMAP3 ISP preview output:0 [] - OMAP3 ISP resizer:0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Source - OMAP3 ISP preview:0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Sink - OMAP3 ISP preview:1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Sink [YUYV 4095x4095 (0,6)/4094x4082] - OMAP3 ISP CCDC:1 [] - OMAP3 ISP preview:1 [] - OMAP3 ISP resizer input:0 [] pad1: Source [YUYV 3312x4095] - OMAP3 ISP resizer output:0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Source - OMAP3 ISP resizer:0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Sink - OMAP3 ISP resizer:1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev
Omap3 ISP + Gstreamer v4l2src
Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0x0 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Sink [SGRBG10 4096x4096] - OMAP3 ISP CCP2 input:0 [] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CCDC:0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Source - OMAP3 ISP CCP2:0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [SGRBG10 4096x4096] pad1: Source [SGRBG10 4096x4096] - OMAP3 ISP CSI2a output:0 [] - OMAP3 ISP CCDC:0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink - OMAP3 ISP CSI2a:1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Sink [UYVY2X8 720x625] - OMAP3 ISP CCP2:1 [] - OMAP3 ISP CSI2a:1 [] - tvp5150 3-005d:0 [ENABLED] pad1: Source [UYVY2X8 720x625] - OMAP3 ISP CCDC output:0 [ENABLED] - OMAP3 ISP resizer:0 [] pad2: Source [UYVY2X8 720x624] - OMAP3 ISP preview:0 [] - OMAP3 ISP AEWB:0 [ENABLED,IMMUTABLE] - OMAP3 ISP AF:0 [ENABLED,IMMUTABLE] - OMAP3 ISP histogram:0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Sink - OMAP3 ISP CCDC:1 [ENABLED] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088] - OMAP3 ISP CCDC:2 [] - OMAP3 ISP preview input:0 [] pad1: Source [YUYV 4082x4088] - OMAP3 ISP preview output:0 [] - OMAP3 ISP resizer:0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Source - OMAP3 ISP preview:0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Sink - OMAP3 ISP preview:1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Sink [YUYV 4095x4095 (0,6)/4094x4082] - OMAP3 ISP CCDC:1 [] - OMAP3 ISP preview:1 [] - OMAP3 ISP resizer input:0 [] pad1: Source [YUYV 3312x4095] - OMAP3 ISP resizer output:0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Source - OMAP3 ISP resizer:0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Sink - OMAP3 ISP resizer:1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Sink - OMAP3 ISP CCDC:2 [ENABLED,IMMUTABLE] - entity 16: tvp5150 3-005d (1 pad, 1 link) type V4L2 subdev subtype
Re: Omap3 ISP + Gstreamer v4l2src
Hi Adam, On Wednesday 07 December 2011 09:02:42 Adam Pledger wrote: Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. No worries. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, Please note that BT.656 support is still experimental, so issues are not unexpected. as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input- infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: [snip] Looks good. The following works nicely: yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2 The problem comes when I try to use gstreamer to capture from /dev/video2, using the following: gst-launch v4l2src device=/dev/video2 ! 'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv This fails with: ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed getting controls attributes on device '/dev/video2'. Additional debug info: v4l2_calls.c(267): gst_v4l2_fill_lists (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed querying control 9963776 on device '/dev/video2'. (25 - Inappropriate ioctl for device) My question is, should this just work? It was my understanding that once the pipeline was configured with media-ctl then the CCDC output pad should behave like a standard V4L2 device node. That's more or less correct. There have been a passionate debate regarding what a standard V4L2 device node is. Not all V4L2 ioctls are mandatory, and no driver implements them all. The OMAP3 ISP driver implements a very small subset of the V4L2 API, and it wasn't clear whether that still qualified as V4L2. After discussions we decided that the V4L2 specification will document profiles, with a set of required ioctls for each of them. The OMAP3 ISP implements the future video streaming profile. I'm not sure what ioctls v4l2src consider as mandatory. The above error related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented by the OMAP3 ISP driver and will likely never be. I don't think that should be considered as mandatory. I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't implemented in the OMAP3 ISP driver. That might change in the future, but I'm not sure yet whether it will. In any case, you might have to modify v4l2src and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago to this mailing list. I realise that this might be something borked with my build dependencies (although I'm pretty certain that v4l2src is being built against the latest libv42) or gstreamer. Before I start digging through the code to work out what is going on with the ioctl handling, I thought I would check to see whether this should work, or whether I am doing something fundamentally silly. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Omap3 ISP + Gstreamer v4l2src
Hi Adam, On 12/07/2011 11:34 AM, Laurent Pinchart wrote: Hi Adam, On Wednesday 07 December 2011 09:02:42 Adam Pledger wrote: Hi Laurent, Firstly, please accept my apologies, for what is very probably a naive question. I'm new to V4L2 and am just getting to grips with how things work. No worries. I'm using a tvp5151 in bt656 mode with the Omap3 ISP, Please note that BT.656 support is still experimental, so issues are not unexpected. as described in this thread (Your YUV support tree + some patches for bt656, based on 2.6.39): http://comments.gmane.org/gmane.linux.drivers.video-input- infrastructure/39539 I am able to capture some frames using yavta, using the media-ctl configuration as follows: media-ctl -v -r -l 'tvp5150 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' media-ctl -v --set-format 'tvp5150 3-005d:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:0 [UYVY2X8 720x625]' media-ctl -v --set-format 'OMAP3 ISP CCDC:1 [UYVY2X8 720x625]' This yields this: [snip] Looks good. The following works nicely: yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2 The problem comes when I try to use gstreamer to capture from /dev/video2, using the following: gst-launch v4l2src device=/dev/video2 ! 'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv This fails with: ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed getting controls attributes on device '/dev/video2'. Additional debug info: v4l2_calls.c(267): gst_v4l2_fill_lists (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed querying control 9963776 on device '/dev/video2'. (25 - Inappropriate ioctl for device) My question is, should this just work? It was my understanding that once the pipeline was configured with media-ctl then the CCDC output pad should behave like a standard V4L2 device node. That's more or less correct. There have been a passionate debate regarding what a standard V4L2 device node is. Not all V4L2 ioctls are mandatory, and no driver implements them all. The OMAP3 ISP driver implements a very small subset of the V4L2 API, and it wasn't clear whether that still qualified as V4L2. After discussions we decided that the V4L2 specification will document profiles, with a set of required ioctls for each of them. The OMAP3 ISP implements the future video streaming profile. I'm not sure what ioctls v4l2src consider as mandatory. The above error related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented by the OMAP3 ISP driver and will likely never be. I don't think that should be considered as mandatory. I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't implemented in the OMAP3 ISP driver. That might change in the future, but I'm not sure yet whether it will. In any case, you might have to modify v4l2src and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago to this mailing list. Here was my submission for ENUM_FMT support: http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html I submitted this in order to be able to use the omap3-isp with GStreamer. I missed the discussion about V4L2 profiles, but when I submitted that patch we discussed whether ENUM_FMT was mandatory. After I pointed out that the V4L2 spec states plainly that it _is_ mandatory, I thought Laurent basically agreed that it was reasonable. Laurent, what do you think about adding ENUM_FMT support now? I realise that this might be something borked with my build dependencies (although I'm pretty certain that v4l2src is being built against the latest libv42) or gstreamer. Before I start digging through the code to work out what is going on with the ioctl handling, I thought I would check to see whether this should work, or whether I am doing something fundamentally silly. -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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Omap3 ISP + Gstreamer v4l2src
Hi Laurent, Michael, snip Please note that BT.656 support is still experimental, so issues are not unexpected. Yes, I was aware that this is not yet fully baked. snip My question is, should this just work? It was my understanding that once the pipeline was configured with media-ctl then the CCDC output pad should behave like a standard V4L2 device node. That's more or less correct. There have been a passionate debate regarding what a standard V4L2 device node is. Not all V4L2 ioctls are mandatory, and no driver implements them all. The OMAP3 ISP driver implements a very small subset of the V4L2 API, and it wasn't clear whether that still qualified as V4L2. After discussions we decided that the V4L2 specification will document profiles, with a set of required ioctls for each of them. The OMAP3 ISP implements the future video streaming profile. I'm not sure what ioctls v4l2src consider as mandatory. The above error related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented by the OMAP3 ISP driver and will likely never be. I don't think that should be considered as mandatory. I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't implemented in the OMAP3 ISP driver. That might change in the future, but I'm not sure yet whether it will. In any case, you might have to modify v4l2src and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago to this mailing list. Here was my submission for ENUM_FMT support: http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html I submitted this in order to be able to use the omap3-isp with GStreamer. I missed the discussion about V4L2 profiles, but when I submitted that patch we discussed whether ENUM_FMT was mandatory. After I pointed out that the V4L2 spec states plainly that it _is_ mandatory, I thought Laurent basically agreed that it was reasonable. Laurent, what do you think about adding ENUM_FMT support now? Thank you both for clarifying the current situation regarding omap3isp / MCF (and Michael for the previous patch, which I will take a look at). This addresses quite a few questions that I have been mulling over in the last few days. snip Best Regards Adam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
