Using omap3-isp-live example application on beagleboard with DVI

Using omap3-isp-live example application on beagleboard with DVI

[John Weber]

Hello,

My goal is to better understand how to write an application that makes use
of the omap3isp and media controller frameworks and v4l2.  I'm attempting to
make use of Laurent's omap3-isp-live example application as a starting point
and play with the AEC/WB capability.

My problem is that when I start the live application, the display turns blue
(it seems when the chromakey fill is done), but no video appears on the
display.  I do think that I'm getting good (or at least statistics) from the
ISP because I can change the view in front of the camera (by putting my hand
in front of the lens) and the gain settings change.

root@beagleboard:~# live

Device /dev/video6 opened: OMAP3 ISP resizer output (media).

viewfinder configured for 2011 1024x768

AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30

Device /dev/video7 opened: omap_vout ().

3 buffers requested.

Buffer 0 mapped at address 0x40279000.

Buffer 1 mapped at address 0x40402000.

Buffer 2 mapped at address 0x4059e000.

3 buffers requested.

Buffer 0 valid.

Buffer 1 valid.

Buffer 2 valid.

AE: factor 3.1250 exposure 2000 sensor gain 12

AE: factor 1.6018 exposure 2000 sensor gain 19

AE: factor 1.1346 exposure 2000 sensor gain 21

AE: factor 1.0446 exposure 2000 sensor gain 21

AE: factor 1.0448 exposure 2000 sensor gain 21

AE: factor 1.0444 exposure 2000 sensor gain 21

AE: factor 1.0443 exposure 2000 sensor gain 21

AE: factor 1.0445 exposure 2000 sensor gain 21

AE: factor 1.0438 exposure 2000 sensor gain 21

AE: factor 1.0448 exposure 2000 sensor gain 21

AE: factor 1.0461 exposure 2000 sensor gain 21

AE: factor 1.0897 exposure 2000 sensor gain 22

AE: factor 2.6543 exposure 2000 sensor gain 58       <   Me obstructing the
camera FOV using my hand causes the factor and gain to rise

AE: factor 1.2345 exposure 2000 sensor gain 71       <

AE: factor 1.1631 exposure 2000 sensor gain 82       <

AE: factor 0.9797 exposure 2000 sensor gain 80       <

AE: factor 0.9709 exposure 2000 sensor gain 77       <

frame rate: 6.597745 fps

AE: factor 0.9633 exposure 2000 sensor gain 74       <

AE: factor 0.6130 exposure 2000 sensor gain 45       <

AE: factor 0.9271 exposure 2000 sensor gain 41       <

AE: factor 1.0130 exposure 2000 sensor gain 41       <

AE: factor 1.0504 exposure 2000 sensor gain 43       <

AE: factor 1.0411 exposure 2000 sensor gain 44       <

AE: factor 1.0271 exposure 2000 sensor gain 45       <

AE: factor 1.0602 exposure 2000 sensor gain 47       <

AE: factor 1.1278 exposure 2000 sensor gain 53       <

AE: factor 1.1870 exposure 2000 sensor gain 62       <

AE: factor 1.1074 exposure 2000 sensor gain 68       <

AE: factor 1.0716 exposure 2000 sensor gain 72       <

AE: factor 0.4074 exposure 2000 sensor gain 29       <

AE: factor 0.8033 exposure 2000 sensor gain 23

AE: factor 0.9741 exposure 2000 sensor gain 22

AE: factor 1.0115 exposure 2000 sensor gain 22


I did have to change the omap_vout driver slightly to increase the buffer
size.  I was getting errors in the application attempted to allocate USERPTR
buffers for 1024x768 frames:

root@beagleboard:~# live

Device /dev/video6 opened: OMAP3 ISP resizer output (media).

viewfinder configured for 2011 1024x768

AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30

Device /dev/video7 opened: omap_vout ().

3 buffers requested.

Buffer 0 mapped at address 0x40302000.

Buffer 1 mapped at address 0x404df000.

Buffer 2 mapped at address 0x4066e000.

3 buffers requested.

Buffer 0 too small (1572864 bytes required, 1474560 bytes available.)  

So, I changed drivers/media/video/omap/omap_voutdef.h to increase the buffer
size slightly.

/* Max Resolution supported by the driver */
#define VID_MAX_WIDTH		1280	/* Largest width */
#define VID_MAX_HEIGHT		768  	/* Largest height */ <-- Was 720

I'm pretty sure that wasn't the only way to solve the problem, but it did
allow the live application to run without errors.

I am using a patched variant of the current Angstrom mainline (3.2.16) with
the MT9P031 sensor and a DVI display on Beagleboard-xM and am able to run
the following commands and see a live video stream on the display.  I
suspect that this indicates that hardware setup works:

media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'

media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 1024x768], "OMAP3 ISP CCDC":2
[SGRBG10 1024x768], "OMAP3 ISP preview":1 [UYVY 10006x760], "OMAP3 ISP
resizer":1 [UYVY 1024x768]'

yavta -f UYVY -s 1024x768 -n 8 --skip 3 --capture=1000 --stdout /dev/video6
| mplayer - -demuxer rawvideo -rawvideo w=1024:h=768:format=uyvy -vo fbdev

Thanks for any tips or assistance!

John

Re: Using omap3-isp-live example application on beagleboard with DVI

[Enric Balletbò i Serra]

Hi John,

2012/9/6 John Weber <rjohnweber@gmail.com>:
> Hello,
>
> My goal is to better understand how to write an application that makes use
> of the omap3isp and media controller frameworks and v4l2.  I'm attempting to
> make use of Laurent's omap3-isp-live example application as a starting point
> and play with the AEC/WB capability.
>
> My problem is that when I start the live application, the display turns blue
> (it seems when the chromakey fill is done), but no video appears on the
> display.  I do think that I'm getting good (or at least statistics) from the
> ISP because I can change the view in front of the camera (by putting my hand
> in front of the lens) and the gain settings change.
>
> root@beagleboard:~# live
>
> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
>
> viewfinder configured for 2011 1024x768
>
> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
>
> Device /dev/video7 opened: omap_vout ().
>
> 3 buffers requested.
>
> Buffer 0 mapped at address 0x40279000.
>
> Buffer 1 mapped at address 0x40402000.
>
> Buffer 2 mapped at address 0x4059e000.
>
> 3 buffers requested.
>
> Buffer 0 valid.
>
> Buffer 1 valid.
>
> Buffer 2 valid.
>
> AE: factor 3.1250 exposure 2000 sensor gain 12
>
> AE: factor 1.6018 exposure 2000 sensor gain 19
>
> AE: factor 1.1346 exposure 2000 sensor gain 21
>
> AE: factor 1.0446 exposure 2000 sensor gain 21
>
> AE: factor 1.0448 exposure 2000 sensor gain 21
>
> AE: factor 1.0444 exposure 2000 sensor gain 21
>
> AE: factor 1.0443 exposure 2000 sensor gain 21
>
> AE: factor 1.0445 exposure 2000 sensor gain 21
>
> AE: factor 1.0438 exposure 2000 sensor gain 21
>
> AE: factor 1.0448 exposure 2000 sensor gain 21
>
> AE: factor 1.0461 exposure 2000 sensor gain 21
>
> AE: factor 1.0897 exposure 2000 sensor gain 22
>
> AE: factor 2.6543 exposure 2000 sensor gain 58       <   Me obstructing the
> camera FOV using my hand causes the factor and gain to rise
>
> AE: factor 1.2345 exposure 2000 sensor gain 71       <
>
> AE: factor 1.1631 exposure 2000 sensor gain 82       <
>
> AE: factor 0.9797 exposure 2000 sensor gain 80       <
>
> AE: factor 0.9709 exposure 2000 sensor gain 77       <
>
> frame rate: 6.597745 fps
>
> AE: factor 0.9633 exposure 2000 sensor gain 74       <
>
> AE: factor 0.6130 exposure 2000 sensor gain 45       <
>
> AE: factor 0.9271 exposure 2000 sensor gain 41       <
>
> AE: factor 1.0130 exposure 2000 sensor gain 41       <
>
> AE: factor 1.0504 exposure 2000 sensor gain 43       <
>
> AE: factor 1.0411 exposure 2000 sensor gain 44       <
>
> AE: factor 1.0271 exposure 2000 sensor gain 45       <
>
> AE: factor 1.0602 exposure 2000 sensor gain 47       <
>
> AE: factor 1.1278 exposure 2000 sensor gain 53       <
>
> AE: factor 1.1870 exposure 2000 sensor gain 62       <
>
> AE: factor 1.1074 exposure 2000 sensor gain 68       <
>
> AE: factor 1.0716 exposure 2000 sensor gain 72       <
>
> AE: factor 0.4074 exposure 2000 sensor gain 29       <
>
> AE: factor 0.8033 exposure 2000 sensor gain 23
>
> AE: factor 0.9741 exposure 2000 sensor gain 22
>
> AE: factor 1.0115 exposure 2000 sensor gain 22
>
>
> I did have to change the omap_vout driver slightly to increase the buffer
> size.  I was getting errors in the application attempted to allocate USERPTR
> buffers for 1024x768 frames:
>
> root@beagleboard:~# live
>
> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
>
> viewfinder configured for 2011 1024x768
>
> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
>
> Device /dev/video7 opened: omap_vout ().
>
> 3 buffers requested.
>
> Buffer 0 mapped at address 0x40302000.
>
> Buffer 1 mapped at address 0x404df000.
>
> Buffer 2 mapped at address 0x4066e000.
>
> 3 buffers requested.
>
> Buffer 0 too small (1572864 bytes required, 1474560 bytes available.)
>
> So, I changed drivers/media/video/omap/omap_voutdef.h to increase the buffer
> size slightly.
>
> /* Max Resolution supported by the driver */
> #define VID_MAX_WIDTH           1280    /* Largest width */
> #define VID_MAX_HEIGHT          768     /* Largest height */ <-- Was 720
>
> I'm pretty sure that wasn't the only way to solve the problem, but it did
> allow the live application to run without errors.
>
> I am using a patched variant of the current Angstrom mainline (3.2.16) with
> the MT9P031 sensor and a DVI display on Beagleboard-xM and am able to run
> the following commands and see a live video stream on the display.  I
> suspect that this indicates that hardware setup works:
>
> media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
>
> media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 1024x768], "OMAP3 ISP CCDC":2
> [SGRBG10 1024x768], "OMAP3 ISP preview":1 [UYVY 10006x760], "OMAP3 ISP
> resizer":1 [UYVY 1024x768]'
>
> yavta -f UYVY -s 1024x768 -n 8 --skip 3 --capture=1000 --stdout /dev/video6
> | mplayer - -demuxer rawvideo -rawvideo w=1024:h=768:format=uyvy -vo fbdev
>
> Thanks for any tips or assistance!
>

I've exactly the same problem. Before try to debug the problem I would
like to know if you solved the problem. Did you solved ?

Regards,
    Enric

> John
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Using omap3-isp-live example application on beagleboard with DVI

[Enric Balletbò i Serra]

Hi John, Laurent,

2012/10/10 Enric Balletbò i Serra <eballetbo@gmail.com>:
> Hi John,
>
> 2012/9/6 John Weber <rjohnweber@gmail.com>:
>> Hello,
>>
>> My goal is to better understand how to write an application that makes use
>> of the omap3isp and media controller frameworks and v4l2.  I'm attempting to
>> make use of Laurent's omap3-isp-live example application as a starting point
>> and play with the AEC/WB capability.
>>
>> My problem is that when I start the live application, the display turns blue
>> (it seems when the chromakey fill is done), but no video appears on the
>> display.  I do think that I'm getting good (or at least statistics) from the
>> ISP because I can change the view in front of the camera (by putting my hand
>> in front of the lens) and the gain settings change.
>>
>> root@beagleboard:~# live
>>
>> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
>>
>> viewfinder configured for 2011 1024x768
>>
>> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
>>
>> Device /dev/video7 opened: omap_vout ().
>>
>> 3 buffers requested.
>>
>> Buffer 0 mapped at address 0x40279000.
>>
>> Buffer 1 mapped at address 0x40402000.
>>
>> Buffer 2 mapped at address 0x4059e000.
>>
>> 3 buffers requested.
>>
>> Buffer 0 valid.
>>
>> Buffer 1 valid.
>>
>> Buffer 2 valid.
>>
>> AE: factor 3.1250 exposure 2000 sensor gain 12
>>
>> AE: factor 1.6018 exposure 2000 sensor gain 19
>>
>> AE: factor 1.1346 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0446 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0448 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0444 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0443 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0445 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0438 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0448 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0461 exposure 2000 sensor gain 21
>>
>> AE: factor 1.0897 exposure 2000 sensor gain 22
>>
>> AE: factor 2.6543 exposure 2000 sensor gain 58       <   Me obstructing the
>> camera FOV using my hand causes the factor and gain to rise
>>
>> AE: factor 1.2345 exposure 2000 sensor gain 71       <
>>
>> AE: factor 1.1631 exposure 2000 sensor gain 82       <
>>
>> AE: factor 0.9797 exposure 2000 sensor gain 80       <
>>
>> AE: factor 0.9709 exposure 2000 sensor gain 77       <
>>
>> frame rate: 6.597745 fps
>>
>> AE: factor 0.9633 exposure 2000 sensor gain 74       <
>>
>> AE: factor 0.6130 exposure 2000 sensor gain 45       <
>>
>> AE: factor 0.9271 exposure 2000 sensor gain 41       <
>>
>> AE: factor 1.0130 exposure 2000 sensor gain 41       <
>>
>> AE: factor 1.0504 exposure 2000 sensor gain 43       <
>>
>> AE: factor 1.0411 exposure 2000 sensor gain 44       <
>>
>> AE: factor 1.0271 exposure 2000 sensor gain 45       <
>>
>> AE: factor 1.0602 exposure 2000 sensor gain 47       <
>>
>> AE: factor 1.1278 exposure 2000 sensor gain 53       <
>>
>> AE: factor 1.1870 exposure 2000 sensor gain 62       <
>>
>> AE: factor 1.1074 exposure 2000 sensor gain 68       <
>>
>> AE: factor 1.0716 exposure 2000 sensor gain 72       <
>>
>> AE: factor 0.4074 exposure 2000 sensor gain 29       <
>>
>> AE: factor 0.8033 exposure 2000 sensor gain 23
>>
>> AE: factor 0.9741 exposure 2000 sensor gain 22
>>
>> AE: factor 1.0115 exposure 2000 sensor gain 22
>>
>>
>> I did have to change the omap_vout driver slightly to increase the buffer
>> size.  I was getting errors in the application attempted to allocate USERPTR
>> buffers for 1024x768 frames:
>>
>> root@beagleboard:~# live
>>
>> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
>>
>> viewfinder configured for 2011 1024x768
>>
>> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
>>
>> Device /dev/video7 opened: omap_vout ().
>>
>> 3 buffers requested.
>>
>> Buffer 0 mapped at address 0x40302000.
>>
>> Buffer 1 mapped at address 0x404df000.
>>
>> Buffer 2 mapped at address 0x4066e000.
>>
>> 3 buffers requested.
>>
>> Buffer 0 too small (1572864 bytes required, 1474560 bytes available.)
>>
>> So, I changed drivers/media/video/omap/omap_voutdef.h to increase the buffer
>> size slightly.
>>
>> /* Max Resolution supported by the driver */
>> #define VID_MAX_WIDTH           1280    /* Largest width */
>> #define VID_MAX_HEIGHT          768     /* Largest height */ <-- Was 720
>>
>> I'm pretty sure that wasn't the only way to solve the problem, but it did
>> allow the live application to run without errors.
>>
>> I am using a patched variant of the current Angstrom mainline (3.2.16) with
>> the MT9P031 sensor and a DVI display on Beagleboard-xM and am able to run
>> the following commands and see a live video stream on the display.  I
>> suspect that this indicates that hardware setup works:
>>
>> media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
>> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
>>
>> media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 1024x768], "OMAP3 ISP CCDC":2
>> [SGRBG10 1024x768], "OMAP3 ISP preview":1 [UYVY 10006x760], "OMAP3 ISP
>> resizer":1 [UYVY 1024x768]'
>>
>> yavta -f UYVY -s 1024x768 -n 8 --skip 3 --capture=1000 --stdout /dev/video6
>> | mplayer - -demuxer rawvideo -rawvideo w=1024:h=768:format=uyvy -vo fbdev
>>
>> Thanks for any tips or assistance!
>>
>
> I've exactly the same problem. Before try to debug the problem I would
> like to know if you solved the problem. Did you solved ?
>

The first change I made and worked (just luck). I made the following change:

-       vo_enable_colorkey(vo, 0x123456);
+       // vo_enable_colorkey(vo, 0x123456);

And now the live application works like a charm. Seems this function
enables a chromakey and the live application can't paint over the
chromakey. Laurent, just to understand what I did, can you explain
this ? Thanks.

Cheers,
    Enric

Re: Using omap3-isp-live example application on beagleboard with DVI

[Laurent Pinchart]

Hi Enric,

On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
> 2012/10/10 Enric Balletbò i Serra <eballetbo@gmail.com>:
> > 2012/9/6 John Weber <rjohnweber@gmail.com>:
> >> Hello,
> >> 
> >> My goal is to better understand how to write an application that makes
> >> use of the omap3isp and media controller frameworks and v4l2.  I'm
> >> attempting to make use of Laurent's omap3-isp-live example application as
> >> a starting point and play with the AEC/WB capability.
> >> 
> >> My problem is that when I start the live application, the display turns
> >> blue (it seems when the chromakey fill is done), but no video appears on
> >> the display.  I do think that I'm getting good (or at least statistics)
> >> from the ISP because I can change the view in front of the camera (by
> >> putting my hand in front of the lens) and the gain settings change.
> >> 
> >> root@beagleboard:~# live
> >> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
> >> viewfinder configured for 2011 1024x768
> >> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
> >> Device /dev/video7 opened: omap_vout ().
> >> 3 buffers requested.
> >> Buffer 0 mapped at address 0x40279000.
> >> Buffer 1 mapped at address 0x40402000.
> >> Buffer 2 mapped at address 0x4059e000.
> >> 3 buffers requested.
> >> Buffer 0 valid.
> >> Buffer 1 valid.
> >> Buffer 2 valid.
> >> AE: factor 3.1250 exposure 2000 sensor gain 12
> >> AE: factor 1.6018 exposure 2000 sensor gain 19
> >> AE: factor 1.1346 exposure 2000 sensor gain 21
> >> AE: factor 1.0446 exposure 2000 sensor gain 21
> >> AE: factor 1.0448 exposure 2000 sensor gain 21
> >> AE: factor 1.0444 exposure 2000 sensor gain 21
> >> AE: factor 1.0443 exposure 2000 sensor gain 21
> >> AE: factor 1.0445 exposure 2000 sensor gain 21
> >> AE: factor 1.0438 exposure 2000 sensor gain 21
> >> AE: factor 1.0448 exposure 2000 sensor gain 21
> >> AE: factor 1.0461 exposure 2000 sensor gain 21
> >> AE: factor 1.0897 exposure 2000 sensor gain 22
> >> AE: factor 2.6543 exposure 2000 sensor gain 58       <   Me obstructing
> >> the camera FOV using my hand causes the factor and gain to rise
> >> AE: factor 1.2345 exposure 2000 sensor gain 71       <
> >> AE: factor 1.1631 exposure 2000 sensor gain 82       <
> >> AE: factor 0.9797 exposure 2000 sensor gain 80       <
> >> AE: factor 0.9709 exposure 2000 sensor gain 77       <
> >> frame rate: 6.597745 fps
> >> AE: factor 0.9633 exposure 2000 sensor gain 74       <
> >> AE: factor 0.6130 exposure 2000 sensor gain 45       <
> >> AE: factor 0.9271 exposure 2000 sensor gain 41       <
> >> AE: factor 1.0130 exposure 2000 sensor gain 41       <
> >> AE: factor 1.0504 exposure 2000 sensor gain 43       <
> >> AE: factor 1.0411 exposure 2000 sensor gain 44       <
> >> AE: factor 1.0271 exposure 2000 sensor gain 45       <
> >> AE: factor 1.0602 exposure 2000 sensor gain 47       <
> >> AE: factor 1.1278 exposure 2000 sensor gain 53       <
> >> AE: factor 1.1870 exposure 2000 sensor gain 62       <
> >> AE: factor 1.1074 exposure 2000 sensor gain 68       <
> >> AE: factor 1.0716 exposure 2000 sensor gain 72       <
> >> AE: factor 0.4074 exposure 2000 sensor gain 29       <
> >> AE: factor 0.8033 exposure 2000 sensor gain 23
> >> AE: factor 0.9741 exposure 2000 sensor gain 22
> >> AE: factor 1.0115 exposure 2000 sensor gain 22
> >> 
> >> I did have to change the omap_vout driver slightly to increase the buffer
> >> size.  I was getting errors in the application attempted to allocate
> >> USERPTR buffers for 1024x768 frames:
> >> 
> >> root@beagleboard:~# live
> >> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
> >> viewfinder configured for 2011 1024x768
> >> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
> >> Device /dev/video7 opened: omap_vout ().
> >> 3 buffers requested.
> >> Buffer 0 mapped at address 0x40302000.
> >> Buffer 1 mapped at address 0x404df000.
> >> Buffer 2 mapped at address 0x4066e000.
> >> 3 buffers requested.
> >> Buffer 0 too small (1572864 bytes required, 1474560 bytes available.)
> >> 
> >> So, I changed drivers/media/video/omap/omap_voutdef.h to increase the
> >> buffer size slightly.
> >> 
> >> /* Max Resolution supported by the driver */
> >> #define VID_MAX_WIDTH           1280    /* Largest width */
> >> #define VID_MAX_HEIGHT          768     /* Largest height */ <-- Was 720
> >> 
> >> I'm pretty sure that wasn't the only way to solve the problem, but it did
> >> allow the live application to run without errors.
> >> 
> >> I am using a patched variant of the current Angstrom mainline (3.2.16)
> >> with the MT9P031 sensor and a DVI display on Beagleboard-xM and am able
> >> to run the following commands and see a live video stream on the display. 
> >> I suspect that this indicates that hardware setup works:
> >> 
> >> media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
> >> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
> >> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
> >> 
> >> media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 1024x768], "OMAP3 ISP
> >> CCDC":2
> >> [SGRBG10 1024x768], "OMAP3 ISP preview":1 [UYVY 10006x760], "OMAP3 ISP
> >> resizer":1 [UYVY 1024x768]'
> >> 
> >> yavta -f UYVY -s 1024x768 -n 8 --skip 3 --capture=1000 --stdout
> >> /dev/video6
> >> 
> >> | mplayer - -demuxer rawvideo -rawvideo w=1024:h=768:format=uyvy -vo
> >> fbdev
> >> 
> >> Thanks for any tips or assistance!
> > 
> > I've exactly the same problem. Before try to debug the problem I would
> > like to know if you solved the problem. Did you solved ?
> 
> The first change I made and worked (just luck). I made the following change:
> 
> -       vo_enable_colorkey(vo, 0x123456);
> +       // vo_enable_colorkey(vo, 0x123456);
> 
> And now the live application works like a charm. Seems this function
> enables a chromakey and the live application can't paint over the
> chromakey. Laurent, just to understand what I did, can you explain
> this ? Thanks.

My guess is that the live application fails to paint the frame buffer with the 
color key. If fb_init() failed the live application would stop, so the 
function succeeds. My guess is thus that the application either paints the 
wrong frame buffer (how many /dev/fb* devices do you have on your system ?), 
or paints it with the wrong color. The code assumes that the frame buffer is 
configured in 32 bit, maybe that's not the case on your system ?

-- 
Regards,

Laurent Pinchart

Re: Using omap3-isp-live example application on beagleboard with DVI

[Enric Balletbo Serra]

[-- Attachment #1: Type: text/plain, Size: 7176 bytes --]

Hi Laurent,

2012/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Enric,
>
> On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
>> 2012/10/10 Enric Balletbò i Serra <eballetbo@gmail.com>:
>> > 2012/9/6 John Weber <rjohnweber@gmail.com>:
>> >> Hello,
>> >>
>> >> My goal is to better understand how to write an application that makes
>> >> use of the omap3isp and media controller frameworks and v4l2.  I'm
>> >> attempting to make use of Laurent's omap3-isp-live example application as
>> >> a starting point and play with the AEC/WB capability.
>> >>
>> >> My problem is that when I start the live application, the display turns
>> >> blue (it seems when the chromakey fill is done), but no video appears on
>> >> the display.  I do think that I'm getting good (or at least statistics)
>> >> from the ISP because I can change the view in front of the camera (by
>> >> putting my hand in front of the lens) and the gain settings change.
>> >>
>> >> root@beagleboard:~# live
>> >> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
>> >> viewfinder configured for 2011 1024x768
>> >> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
>> >> Device /dev/video7 opened: omap_vout ().
>> >> 3 buffers requested.
>> >> Buffer 0 mapped at address 0x40279000.
>> >> Buffer 1 mapped at address 0x40402000.
>> >> Buffer 2 mapped at address 0x4059e000.
>> >> 3 buffers requested.
>> >> Buffer 0 valid.
>> >> Buffer 1 valid.
>> >> Buffer 2 valid.
>> >> AE: factor 3.1250 exposure 2000 sensor gain 12
>> >> AE: factor 1.6018 exposure 2000 sensor gain 19
>> >> AE: factor 1.1346 exposure 2000 sensor gain 21
>> >> AE: factor 1.0446 exposure 2000 sensor gain 21
>> >> AE: factor 1.0448 exposure 2000 sensor gain 21
>> >> AE: factor 1.0444 exposure 2000 sensor gain 21
>> >> AE: factor 1.0443 exposure 2000 sensor gain 21
>> >> AE: factor 1.0445 exposure 2000 sensor gain 21
>> >> AE: factor 1.0438 exposure 2000 sensor gain 21
>> >> AE: factor 1.0448 exposure 2000 sensor gain 21
>> >> AE: factor 1.0461 exposure 2000 sensor gain 21
>> >> AE: factor 1.0897 exposure 2000 sensor gain 22
>> >> AE: factor 2.6543 exposure 2000 sensor gain 58       <   Me obstructing
>> >> the camera FOV using my hand causes the factor and gain to rise
>> >> AE: factor 1.2345 exposure 2000 sensor gain 71       <
>> >> AE: factor 1.1631 exposure 2000 sensor gain 82       <
>> >> AE: factor 0.9797 exposure 2000 sensor gain 80       <
>> >> AE: factor 0.9709 exposure 2000 sensor gain 77       <
>> >> frame rate: 6.597745 fps
>> >> AE: factor 0.9633 exposure 2000 sensor gain 74       <
>> >> AE: factor 0.6130 exposure 2000 sensor gain 45       <
>> >> AE: factor 0.9271 exposure 2000 sensor gain 41       <
>> >> AE: factor 1.0130 exposure 2000 sensor gain 41       <
>> >> AE: factor 1.0504 exposure 2000 sensor gain 43       <
>> >> AE: factor 1.0411 exposure 2000 sensor gain 44       <
>> >> AE: factor 1.0271 exposure 2000 sensor gain 45       <
>> >> AE: factor 1.0602 exposure 2000 sensor gain 47       <
>> >> AE: factor 1.1278 exposure 2000 sensor gain 53       <
>> >> AE: factor 1.1870 exposure 2000 sensor gain 62       <
>> >> AE: factor 1.1074 exposure 2000 sensor gain 68       <
>> >> AE: factor 1.0716 exposure 2000 sensor gain 72       <
>> >> AE: factor 0.4074 exposure 2000 sensor gain 29       <
>> >> AE: factor 0.8033 exposure 2000 sensor gain 23
>> >> AE: factor 0.9741 exposure 2000 sensor gain 22
>> >> AE: factor 1.0115 exposure 2000 sensor gain 22
>> >>
>> >> I did have to change the omap_vout driver slightly to increase the buffer
>> >> size.  I was getting errors in the application attempted to allocate
>> >> USERPTR buffers for 1024x768 frames:
>> >>
>> >> root@beagleboard:~# live
>> >> Device /dev/video6 opened: OMAP3 ISP resizer output (media).
>> >> viewfinder configured for 2011 1024x768
>> >> AEWB: #win 10x7 start 16x74 size 256x256 inc 30x30
>> >> Device /dev/video7 opened: omap_vout ().
>> >> 3 buffers requested.
>> >> Buffer 0 mapped at address 0x40302000.
>> >> Buffer 1 mapped at address 0x404df000.
>> >> Buffer 2 mapped at address 0x4066e000.
>> >> 3 buffers requested.
>> >> Buffer 0 too small (1572864 bytes required, 1474560 bytes available.)
>> >>
>> >> So, I changed drivers/media/video/omap/omap_voutdef.h to increase the
>> >> buffer size slightly.
>> >>
>> >> /* Max Resolution supported by the driver */
>> >> #define VID_MAX_WIDTH           1280    /* Largest width */
>> >> #define VID_MAX_HEIGHT          768     /* Largest height */ <-- Was 720
>> >>
>> >> I'm pretty sure that wasn't the only way to solve the problem, but it did
>> >> allow the live application to run without errors.
>> >>
>> >> I am using a patched variant of the current Angstrom mainline (3.2.16)
>> >> with the MT9P031 sensor and a DVI display on Beagleboard-xM and am able
>> >> to run the following commands and see a live video stream on the display.
>> >> I suspect that this indicates that hardware setup works:
>> >>
>> >> media-ctl -v -r -l '"mt9p031 2-0048":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP
>> >> CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP
>> >> resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]'
>> >>
>> >> media-ctl -v -f '"mt9p031 2-0048":0 [SGRBG12 1024x768], "OMAP3 ISP
>> >> CCDC":2
>> >> [SGRBG10 1024x768], "OMAP3 ISP preview":1 [UYVY 10006x760], "OMAP3 ISP
>> >> resizer":1 [UYVY 1024x768]'
>> >>
>> >> yavta -f UYVY -s 1024x768 -n 8 --skip 3 --capture=1000 --stdout
>> >> /dev/video6
>> >>
>> >> | mplayer - -demuxer rawvideo -rawvideo w=1024:h=768:format=uyvy -vo
>> >> fbdev
>> >>
>> >> Thanks for any tips or assistance!
>> >
>> > I've exactly the same problem. Before try to debug the problem I would
>> > like to know if you solved the problem. Did you solved ?
>>
>> The first change I made and worked (just luck). I made the following change:
>>
>> -       vo_enable_colorkey(vo, 0x123456);
>> +       // vo_enable_colorkey(vo, 0x123456);
>>
>> And now the live application works like a charm. Seems this function
>> enables a chromakey and the live application can't paint over the
>> chromakey. Laurent, just to understand what I did, can you explain
>> this ? Thanks.
>
> My guess is that the live application fails to paint the frame buffer with the
> color key. If fb_init() failed the live application would stop, so the
> function succeeds. My guess is thus that the application either paints the
> wrong frame buffer (how many /dev/fb* devices do you have on your system ?),

I checked again and no, it opens the correct framebuffer.

> or paints it with the wrong color. The code assumes that the frame buffer is
> configured in 32 bit, maybe that's not the case on your system ?

This was my problem, and I suspect it's the John problem. My system
was configured in 16 bit instead of 32 bit.

FYI, I made a patch that adds this check to the live application. I
did not know where send the patch so I attached to this email.

Thank you very much for your support.

Regards,
    Enric

[-- Attachment #2: 0001-live-Fail-if-the-frame-buffer-is-not-configured-in-3.patch --]
[-- Type: application/octet-stream, Size: 1609 bytes --]

From 91a933f915d345e420fa6b4e01232dd84ea3fed7 Mon Sep 17 00:00:00 2001
From: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Date: Mon, 15 Oct 2012 13:22:44 +0200
Subject: [PATCH] live: Fail if the frame buffer is not configured in 32 bits.

The code assumes that the frame buffer is configured in 32 bit. If this
is not the case of your system the fb_init() doesn't fail and the live
application doesn't stop. When this happens the display turns blue but
no video appears on the display.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
---
 live.c |   26 +++++++++++++++++++++++++-
 1 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/live.c b/live.c
index 512c529..9032e01 100644
--- a/live.c
+++ b/live.c
@@ -265,8 +265,32 @@ static int fb_init(struct v4l2_rect *rect)
 	struct fb_var_screeninfo var;
 	unsigned int i;
 	void *mem = NULL;
-	int ret;
+	int ret, val;
 	int fd;
+	FILE* file;
+
+	/* Read the framebuffer bit-per-pixel from sysfs. */
+	file = fopen("/sys/class/graphics/fb0/bits_per_pixel", "r");
+	if (file == NULL) {
+		perror("Failed to open bits_per_pixel for fb0\n");
+		return -1;
+	}
+
+	ret = fscanf(file, "%d", &val);
+	if (ret == EOF) {
+		if (ferror(file))
+			perror("fscanf");
+		else
+			printf("error: fscanf matching failure\n");
+		return -1;
+	}
+	if (val != 32) {
+		printf("error: doesn't work in %dbit colour depth\n", val);
+		printf("The code assumes that the frame buffer is configured "
+			"in 32 bit, that's not the case on your system.\n");
+		return -1;
+	}
+	fclose(file);
 
 	fd = open("/dev/fb0", O_RDWR);
 	if (fd == -1)
-- 
1.7.5.4

Re: Using omap3-isp-live example application on beagleboard with DVI

[Laurent Pinchart]

Hi Enric,

On Monday 15 October 2012 14:03:20 Enric Balletbo Serra wrote:
> 2012/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> > On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
> >> 2012/10/10 Enric Balletbò i Serra <eballetbo@gmail.com>:
> >> > 2012/9/6 John Weber <rjohnweber@gmail.com>:
> >> >> Hello,
> >> >> 
> >> >> My goal is to better understand how to write an application that makes
> >> >> use of the omap3isp and media controller frameworks and v4l2.  I'm
> >> >> attempting to make use of Laurent's omap3-isp-live example application
> >> >> as a starting point and play with the AEC/WB capability.
> >> >> 
> >> >> My problem is that when I start the live application, the display
> >> >> turns blue (it seems when the chromakey fill is done), but no video
> >> >> appears on the display.  I do think that I'm getting good (or at least
> >> >> statistics) from the ISP because I can change the view in front of the
> >> >> camera (by putting my hand in front of the lens) and the gain settings
> >> >> change.

[snip]

> >> > I've exactly the same problem. Before try to debug the problem I would
> >> > like to know if you solved the problem. Did you solved ?
> >> 
> >> The first change I made and worked (just luck). I made the following
> >> change:
> >> 
> >> -       vo_enable_colorkey(vo, 0x123456);
> >> +       // vo_enable_colorkey(vo, 0x123456);
> >> 
> >> And now the live application works like a charm. Seems this function
> >> enables a chromakey and the live application can't paint over the
> >> chromakey. Laurent, just to understand what I did, can you explain
> >> this ? Thanks.
> > 
> > My guess is that the live application fails to paint the frame buffer with
> > the color key. If fb_init() failed the live application would stop, so
> > the function succeeds. My guess is thus that the application either
> > paints the wrong frame buffer (how many /dev/fb* devices do you have on
> > your system ?),
>
> I checked again and no, it opens the correct framebuffer.
> 
> > or paints it with the wrong color. The code assumes that the frame buffer
> > is configured in 32 bit, maybe that's not the case on your system ?
> 
> This was my problem, and I suspect it's the John problem. My system was
> configured in 16 bit instead of 32 bit.
> 
> FYI, I made a patch that adds this check to the live application. I did not
> know where send the patch so I attached to this email.

Thank you for the patch.

Instead of failing what would be more interesting would be to get the 
application to work in 16bpp mode as well. For that you will need to paint the 
frame buffer with a 16bpp color, and set the colorkey to the same value. Would 
you be able to try that ?

-- 
Regards,

Laurent Pinchart

Re: Using omap3-isp-live example application on beagleboard with DVI

[Enric Balletbo Serra]

[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]

Hi Laurent,

2012/10/17 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Enric,
>
> On Monday 15 October 2012 14:03:20 Enric Balletbo Serra wrote:
>> 2012/10/11 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>> > On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
>> >> 2012/10/10 Enric Balletbò i Serra <eballetbo@gmail.com>:
>> >> > 2012/9/6 John Weber <rjohnweber@gmail.com>:
>> >> >> Hello,
>> >> >>
>> >> >> My goal is to better understand how to write an application that makes
>> >> >> use of the omap3isp and media controller frameworks and v4l2.  I'm
>> >> >> attempting to make use of Laurent's omap3-isp-live example application
>> >> >> as a starting point and play with the AEC/WB capability.
>> >> >>
>> >> >> My problem is that when I start the live application, the display
>> >> >> turns blue (it seems when the chromakey fill is done), but no video
>> >> >> appears on the display.  I do think that I'm getting good (or at least
>> >> >> statistics) from the ISP because I can change the view in front of the
>> >> >> camera (by putting my hand in front of the lens) and the gain settings
>> >> >> change.
>
> [snip]
>
>> >> > I've exactly the same problem. Before try to debug the problem I would
>> >> > like to know if you solved the problem. Did you solved ?
>> >>
>> >> The first change I made and worked (just luck). I made the following
>> >> change:
>> >>
>> >> -       vo_enable_colorkey(vo, 0x123456);
>> >> +       // vo_enable_colorkey(vo, 0x123456);
>> >>
>> >> And now the live application works like a charm. Seems this function
>> >> enables a chromakey and the live application can't paint over the
>> >> chromakey. Laurent, just to understand what I did, can you explain
>> >> this ? Thanks.
>> >
>> > My guess is that the live application fails to paint the frame buffer with
>> > the color key. If fb_init() failed the live application would stop, so
>> > the function succeeds. My guess is thus that the application either
>> > paints the wrong frame buffer (how many /dev/fb* devices do you have on
>> > your system ?),
>>
>> I checked again and no, it opens the correct framebuffer.
>>
>> > or paints it with the wrong color. The code assumes that the frame buffer
>> > is configured in 32 bit, maybe that's not the case on your system ?
>>
>> This was my problem, and I suspect it's the John problem. My system was
>> configured in 16 bit instead of 32 bit.
>>
>> FYI, I made a patch that adds this check to the live application. I did not
>> know where send the patch so I attached to this email.
>
> Thank you for the patch.
>
> Instead of failing what would be more interesting would be to get the
> application to work in 16bpp mode as well. For that you will need to paint the
> frame buffer with a 16bpp color, and set the colorkey to the same value. Would
> you be able to try that ?
>

New patch attached, comments are welcome as I'm newbie with video devices.

Regards,
    Enric

[-- Attachment #2: 0001-live-Get-the-application-to-work-in-16bpp-mode.patch --]
[-- Type: application/octet-stream, Size: 3013 bytes --]

From 6e2274b94cec9c1d03f5821483920de69e5aba8e Mon Sep 17 00:00:00 2001
From: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Date: Wed, 17 Oct 2012 11:22:59 +0200
Subject: [PATCH] live: Get the application to work in 16bpp mode.

Set the framebuffer with a 16bpp color and set the colorkey to the same
value when frame buffer is configured in 16 bit. With this patch we
support 16 and 32 bit, if this is not the case the application fails.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
---
 live.c |   54 +++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/live.c b/live.c
index 512c529..762c9f3 100644
--- a/live.c
+++ b/live.c
@@ -259,7 +259,32 @@ static const char *video_out_find(void)
  * Frame buffer
  */
 
-static int fb_init(struct v4l2_rect *rect)
+static int fb_get_color_depth(void)
+{
+	int ret, bpp;
+	FILE *file;
+
+	/* Read the framebuffer bit-per-pixel from sysfs. */
+	file = fopen("/sys/class/graphics/fb0/bits_per_pixel", "r");
+	if (file == NULL) {
+		perror("Failed to open bits_per_pixel for fb0\n");
+		return -1;
+	}
+
+	ret = fscanf(file, "%d", &bpp);
+	if (ret == EOF) {
+		if (ferror(file))
+			perror("fscanf");
+		else
+			printf("error: fscanf matching failure\n");
+		return -1;
+	}
+	fclose(file);
+
+	return bpp;
+}
+
+static int fb_init(struct v4l2_rect *rect, int bpp)
 {
 	struct fb_fix_screeninfo fix;
 	struct fb_var_screeninfo var;
@@ -293,8 +318,17 @@ static int fb_init(struct v4l2_rect *rect)
 	}
 
 	/* Fill the frame buffer with the background color. */
-	for (i = 0; i < fix.smem_len; i += 4)
-		*(uint32_t *)(mem + i) = 0x00123456;
+	if (bpp == 16)
+		for (i = 0; i < fix.smem_len; i += 2)
+			*(uint16_t *)(mem + i) = 0x1234;
+	else if (bpp == 32)
+		for (i = 0; i < fix.smem_len; i += 4)
+			*(uint32_t *)(mem + i) = 0x00123456;
+	else {
+		printf("error: doesn't work in %dbit colour depth\n", bpp);
+		ret = -1;
+		goto done;
+	}
 
 	/* Return the frame buffer size. */
 	rect->left = var.xoffset;
@@ -368,6 +402,7 @@ int main(int argc __attribute__((__unused__)), char *argv[] __attribute__((__unu
 	float fps;
 	int ret;
 	int c;
+	int bpp;
 
 	iq_params_init(&iq_params);
 
@@ -403,8 +438,14 @@ int main(int argc __attribute__((__unused__)), char *argv[] __attribute__((__unu
 
 	events_init(&events);
 
+	bpp = fb_get_color_depth();
+	if (bpp < 0) {
+		printf("error: doesn't work in %dbit colour depth\n", bpp);
+		goto cleanup;
+	}
+
 	memset(&rect, 0, sizeof rect);
-	ret = fb_init(&rect);
+	ret = fb_init(&rect, bpp);
 	if (ret < 0) {
 		printf("error: unable to initialize frame buffer\n");
 		goto cleanup;
@@ -460,7 +501,10 @@ int main(int argc __attribute__((__unused__)), char *argv[] __attribute__((__unu
 		goto cleanup;
 	}
 
-	vo_enable_colorkey(vo, 0x123456);
+	if (bpp == 32)
+		vo_enable_colorkey(vo, 0x123456);
+	else
+		vo_enable_colorkey(vo, 0x1234);
 
 	/* Allocate a buffers pool and use it for the viewfinder. */
 	pool = vo_get_pool(vo);
-- 
1.7.5.4

Re: Using omap3-isp-live example application on beagleboard with DVI

[Laurent Pinchart]

Hi Enric,

On Wednesday 17 October 2012 11:35:37 Enric Balletbo Serra wrote:
> 2012/10/17 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:

[snip]

> > Instead of failing what would be more interesting would be to get the
> > application to work in 16bpp mode as well. For that you will need to paint
> > the frame buffer with a 16bpp color, and set the colorkey to the same
> > value. Would you be able to try that ?
> 
> New patch attached, comments are welcome as I'm newbie with video devices.

Thank you for the patch. In the future could you please send patches inline 
instead of attached (git send-email is a very useful tool for that) ? It would 
make review easier.

You can get the bpp value directly from the frame buffer API without going 
through sysfs. I've modified your patch accordingly, have added support for 
24bpp as well and pushed the result to the repository.

-- 
Regards,

Laurent Pinchart

Re: Using omap3-isp-live example application on beagleboard with DVI

[Enric Balletbo Serra]

Hi Laurent,

2012/10/19 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Enric,
>
> On Wednesday 17 October 2012 11:35:37 Enric Balletbo Serra wrote:
>> 2012/10/17 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
>
> [snip]
>
>> > Instead of failing what would be more interesting would be to get the
>> > application to work in 16bpp mode as well. For that you will need to paint
>> > the frame buffer with a 16bpp color, and set the colorkey to the same
>> > value. Would you be able to try that ?
>>
>> New patch attached, comments are welcome as I'm newbie with video devices.
>
> Thank you for the patch. In the future could you please send patches inline
> instead of attached (git send-email is a very useful tool for that) ? It would
> make review easier.
>

Ok, I'll do.

> You can get the bpp value directly from the frame buffer API without going
> through sysfs. I've modified your patch accordingly, have added support for
> 24bpp as well and pushed the result to the repository.
>

Cool, I liked your patch, today I learned a bit more.


Regards,

Enric Balletbo