* Using omap3-isp-live example application on beagleboard with DVI @ 2012-09-06 16:43 John Weber 2012-10-10 13:24 ` Enric Balletbò i Serra 0 siblings, 1 reply; 9+ messages in thread From: John Weber @ 2012-09-06 16:43 UTC (permalink / raw) To: linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using omap3-isp-live example application on beagleboard with DVI 2012-09-06 16:43 Using omap3-isp-live example application on beagleboard with DVI John Weber @ 2012-10-10 13:24 ` Enric Balletbò i Serra 2012-10-11 8:14 ` Enric Balletbò i Serra 0 siblings, 1 reply; 9+ messages in thread From: Enric Balletbò i Serra @ 2012-10-10 13:24 UTC (permalink / raw) To: John Weber; +Cc: linux-media, Laurent Pinchart 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using omap3-isp-live example application on beagleboard with DVI 2012-10-10 13:24 ` Enric Balletbò i Serra @ 2012-10-11 8:14 ` Enric Balletbò i Serra 2012-10-11 21:56 ` Laurent Pinchart 0 siblings, 1 reply; 9+ messages in thread From: Enric Balletbò i Serra @ 2012-10-11 8:14 UTC (permalink / raw) To: John Weber; +Cc: linux-media, Laurent Pinchart 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using omap3-isp-live example application on beagleboard with DVI 2012-10-11 8:14 ` Enric Balletbò i Serra @ 2012-10-11 21:56 ` Laurent Pinchart 2012-10-15 12:03 ` Enric Balletbo Serra 0 siblings, 1 reply; 9+ messages in thread From: Laurent Pinchart @ 2012-10-11 21:56 UTC (permalink / raw) To: Enric Balletbò i Serra; +Cc: John Weber, linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using omap3-isp-live example application on beagleboard with DVI 2012-10-11 21:56 ` Laurent Pinchart @ 2012-10-15 12:03 ` Enric Balletbo Serra 2012-10-17 0:21 ` Laurent Pinchart 0 siblings, 1 reply; 9+ messages in thread From: Enric Balletbo Serra @ 2012-10-15 12:03 UTC (permalink / raw) To: Laurent Pinchart; +Cc: John Weber, linux-media [-- 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Using omap3-isp-live example application on beagleboard with DVI 2012-10-15 12:03 ` Enric Balletbo Serra @ 2012-10-17 0:21 ` Laurent Pinchart 2012-10-17 9:35 ` Enric Balletbo Serra 0 siblings, 1 reply; 9+ messages in thread From: Laurent Pinchart @ 2012-10-17 0:21 UTC (permalink / raw) To: Enric Balletbo Serra; +Cc: John Weber, linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using omap3-isp-live example application on beagleboard with DVI 2012-10-17 0:21 ` Laurent Pinchart @ 2012-10-17 9:35 ` Enric Balletbo Serra 2012-10-19 14:01 ` Laurent Pinchart 0 siblings, 1 reply; 9+ messages in thread From: Enric Balletbo Serra @ 2012-10-17 9:35 UTC (permalink / raw) To: Laurent Pinchart; +Cc: John Weber, linux-media [-- 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Using omap3-isp-live example application on beagleboard with DVI 2012-10-17 9:35 ` Enric Balletbo Serra @ 2012-10-19 14:01 ` Laurent Pinchart 2012-10-19 17:25 ` Enric Balletbo Serra 0 siblings, 1 reply; 9+ messages in thread From: Laurent Pinchart @ 2012-10-19 14:01 UTC (permalink / raw) To: Enric Balletbo Serra; +Cc: John Weber, linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Using omap3-isp-live example application on beagleboard with DVI 2012-10-19 14:01 ` Laurent Pinchart @ 2012-10-19 17:25 ` Enric Balletbo Serra 0 siblings, 0 replies; 9+ messages in thread From: Enric Balletbo Serra @ 2012-10-19 17:25 UTC (permalink / raw) To: Laurent Pinchart; +Cc: John Weber, linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-10-19 17:25 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-06 16:43 Using omap3-isp-live example application on beagleboard with DVI John Weber 2012-10-10 13:24 ` Enric Balletbò i Serra 2012-10-11 8:14 ` Enric Balletbò i Serra 2012-10-11 21:56 ` Laurent Pinchart 2012-10-15 12:03 ` Enric Balletbo Serra 2012-10-17 0:21 ` Laurent Pinchart 2012-10-17 9:35 ` Enric Balletbo Serra 2012-10-19 14:01 ` Laurent Pinchart 2012-10-19 17:25 ` Enric Balletbo Serra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).