PXP test applications

PXP test applications

[Eric Nelson]

Hi all,

Does anyone know how to run the pxp_test.out program
from /unit_tests?

I can run it, but it's not clear what is supposed to happen.

root@nitrogen6x:/unit_tests# ./pxp_test.out -H
Usage: ./pxp_test.out -I "<options for each instance>" -H display this help

options for each instance
   -o <output file> Write output to file
 	If no output is specified, default is panel
   -r <rotation angle>
   -h <horizontal flip>
   -v <vertical flip>
   -l <left position for display>
   -t <top position for display>
   -i <pixel inversion>

I can run it, but I'm not sure what it's supposed to do.

root@nitrogen6x:/unit_tests# ./pxp_test.out -I "-h -v -l 10 -t 100 -i
akiyo.mp4"
pxp_test.c:358 opening this fb_dev - /dev/fb0
pxp_test.c:358 opening this fb_dev - /dev/fb1
pxp_test.c:358 opening this fb_dev - /dev/fb2
pxp_test.c:358 opening this fb_dev - /dev/fb3
pxp_test.c:361 Unable to open /dev/fb3
root@nitrogen6x:/unit_tests# echo $?
0

Carlos pointed out that we had been missing a bit
from our SDL device trees:
	https://github.com/boundarydevices/linux-imx6/commit/5be9587

And I was hoping to actually exercise the driver and
am lost about where to start.

The imxpxpvideosink seems to lock up with a message of:
	pxp_dispatch_thread: task is timeout

Regards,


Eric

Re: PXP test applications

[Daiane Angolini]

On Thu, Apr 9, 2015 at 6:13 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Hi all,
>
> Does anyone know how to run the pxp_test.out program
> from /unit_tests?
>
> I can run it, but it's not clear what is supposed to happen.
>
> root@nitrogen6x:/unit_tests# ./pxp_test.out -H
> Usage: ./pxp_test.out -I "<options for each instance>" -H display this help
>
> options for each instance
>    -o <output file> Write output to file
>         If no output is specified, default is panel
>    -r <rotation angle>
>    -h <horizontal flip>
>    -v <vertical flip>
>    -l <left position for display>
>    -t <top position for display>
>    -i <pixel inversion>
>
> I can run it, but I'm not sure what it's supposed to do.
>
> root@nitrogen6x:/unit_tests# ./pxp_test.out -I "-h -v -l 10 -t 100 -i
> akiyo.mp4"

If you look under /unit_test folder, you find a pxp_autorun.sh script
(or something like that)

The autorun* scripts are a set of command lines to run "automatically"
the *.out test.

Maybe it can help you figure out how to use it

Daiane

> pxp_test.c:358 opening this fb_dev - /dev/fb0
> pxp_test.c:358 opening this fb_dev - /dev/fb1
> pxp_test.c:358 opening this fb_dev - /dev/fb2
> pxp_test.c:358 opening this fb_dev - /dev/fb3
> pxp_test.c:361 Unable to open /dev/fb3
> root@nitrogen6x:/unit_tests# echo $?
> 0
>
> Carlos pointed out that we had been missing a bit
> from our SDL device trees:
>         https://github.com/boundarydevices/linux-imx6/commit/5be9587
>
> And I was hoping to actually exercise the driver and
> am lost about where to start.
>
> The imxpxpvideosink seems to lock up with a message of:
>         pxp_dispatch_thread: task is timeout
>
> Regards,
>
>
> Eric
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: PXP test applications

[Eric Nelson]

Thanks Daiane,

On 04/10/2015 05:09 AM, Daiane Angolini wrote:
> On Thu, Apr 9, 2015 at 6:13 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> Hi all,
>>
>> Does anyone know how to run the pxp_test.out program
>> from /unit_tests?
>>
>> I can run it, but it's not clear what is supposed to happen.
>>
>> root@nitrogen6x:/unit_tests# ./pxp_test.out -H
>> Usage: ./pxp_test.out -I "<options for each instance>" -H display this help
>>
>> options for each instance
>>    -o <output file> Write output to file
>>         If no output is specified, default is panel
>>    -r <rotation angle>
>>    -h <horizontal flip>
>>    -v <vertical flip>
>>    -l <left position for display>
>>    -t <top position for display>
>>    -i <pixel inversion>
>>
>> I can run it, but I'm not sure what it's supposed to do.
>>
>> root@nitrogen6x:/unit_tests# ./pxp_test.out -I "-h -v -l 10 -t 100 -i
>> akiyo.mp4"
> 
> If you look under /unit_test folder, you find a pxp_autorun.sh script
> (or something like that)
> 
> The autorun* scripts are a set of command lines to run "automatically"
> the *.out test.
> 
> Maybe it can help you figure out how to use it
> 

Oddly, the file pxp_autorun.sh isn't a script:

~/yocto/build/tmp/work/nitrogen6x-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/image/unit_tests$
ls -l *pxp*
-rwxr-xr-x 1 ericn ericn 382803 Mar 30 20:34 autorun-pxp.sh
-rwxr-xr-x 1 ericn ericn 382803 Mar 30 20:34 pxp_test.out
~/yocto/build/tmp/work/nitrogen6x-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/image/unit_tests$
file autorun-pxp.sh
autorun-pxp.sh: ELF 32-bit LSB  executable, ARM, EABI5 version 1...

Something appears to be broken in the build process, since I do
find a script with some sample command-lines in the source tree:

pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -dst 0:0:352:240 -a 100
-w 2 fb-352x240.yuv  BLANK
pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 0 -r 90 fb-352x240.yuv
 BLANK
pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 100 -o rgb24_file.s1
fb-352x240.yuv  BLANK
pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 100 -r 180
fb-352x240.yuv rgb24_file.s1
pxp_v4l2_out_test.sh (END)

Regards,


Eric

Re: PXP test applications

[Daiane Angolini]

On Fri, Apr 10, 2015 at 11:47 AM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Thanks Daiane,
>
> On 04/10/2015 05:09 AM, Daiane Angolini wrote:
>> On Thu, Apr 9, 2015 at 6:13 PM, Eric Nelson
>> <eric.nelson@boundarydevices.com> wrote:
>>> Hi all,
>>>
>>> Does anyone know how to run the pxp_test.out program
>>> from /unit_tests?
>>>
>>> I can run it, but it's not clear what is supposed to happen.
>>>
>>> root@nitrogen6x:/unit_tests# ./pxp_test.out -H
>>> Usage: ./pxp_test.out -I "<options for each instance>" -H display this help
>>>
>>> options for each instance
>>>    -o <output file> Write output to file
>>>         If no output is specified, default is panel
>>>    -r <rotation angle>
>>>    -h <horizontal flip>
>>>    -v <vertical flip>
>>>    -l <left position for display>
>>>    -t <top position for display>
>>>    -i <pixel inversion>
>>>
>>> I can run it, but I'm not sure what it's supposed to do.
>>>
>>> root@nitrogen6x:/unit_tests# ./pxp_test.out -I "-h -v -l 10 -t 100 -i
>>> akiyo.mp4"
>>
>> If you look under /unit_test folder, you find a pxp_autorun.sh script
>> (or something like that)
>>
>> The autorun* scripts are a set of command lines to run "automatically"
>> the *.out test.
>>
>> Maybe it can help you figure out how to use it
>>
>
> Oddly, the file pxp_autorun.sh isn't a script:

I was able to run the script some version in the recent past, so I
think it's a regression.

(I was able to run the script with error, so for me it was useless)


Daiane
>
> ~/yocto/build/tmp/work/nitrogen6x-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/image/unit_tests$
> ls -l *pxp*
> -rwxr-xr-x 1 ericn ericn 382803 Mar 30 20:34 autorun-pxp.sh
> -rwxr-xr-x 1 ericn ericn 382803 Mar 30 20:34 pxp_test.out
> ~/yocto/build/tmp/work/nitrogen6x-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/image/unit_tests$
> file autorun-pxp.sh
> autorun-pxp.sh: ELF 32-bit LSB  executable, ARM, EABI5 version 1...
>
> Something appears to be broken in the build process, since I do
> find a script with some sample command-lines in the source tree:
>
> pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -dst 0:0:352:240 -a 100
> -w 2 fb-352x240.yuv  BLANK
> pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 0 -r 90 fb-352x240.yuv
>  BLANK
> pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 100 -o rgb24_file.s1
> fb-352x240.yuv  BLANK
> pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -a 100 -r 180
> fb-352x240.yuv rgb24_file.s1
> pxp_v4l2_out_test.sh (END)
>
> Regards,
>
>
> Eric

Re: PXP test applications

[Eric Nelson]

Hi Daiane,

On 04/10/2015 08:58 AM, Daiane Angolini wrote:
> On Fri, Apr 10, 2015 at 11:47 AM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> Thanks Daiane,
>>
>> On 04/10/2015 05:09 AM, Daiane Angolini wrote:
>>> On Thu, Apr 9, 2015 at 6:13 PM, Eric Nelson
>>> <eric.nelson@boundarydevices.com> wrote:
>>>> Hi all,
>>>>
>>>> Does anyone know how to run the pxp_test.out program
>>>> from /unit_tests?
>>>>
>>>> I can run it, but it's not clear what is supposed to happen.
>>>>
>>>> root@nitrogen6x:/unit_tests# ./pxp_test.out -H
>>>> Usage: ./pxp_test.out -I "<options for each instance>" -H display this help
>>>>
>>>> options for each instance
>>>>    -o <output file> Write output to file
>>>>         If no output is specified, default is panel
>>>>    -r <rotation angle>
>>>>    -h <horizontal flip>
>>>>    -v <vertical flip>
>>>>    -l <left position for display>
>>>>    -t <top position for display>
>>>>    -i <pixel inversion>
>>>>
>>>> I can run it, but I'm not sure what it's supposed to do.
>>>>
>>>> root@nitrogen6x:/unit_tests# ./pxp_test.out -I "-h -v -l 10 -t 100 -i
>>>> akiyo.mp4"
>>>
>>> If you look under /unit_test folder, you find a pxp_autorun.sh script
>>> (or something like that)
>>>
>>> The autorun* scripts are a set of command lines to run "automatically"
>>> the *.out test.
>>>
>>> Maybe it can help you figure out how to use it
>>>
>>
>> Oddly, the file pxp_autorun.sh isn't a script:
> 
> I was able to run the script some version in the recent past, so I
> think it's a regression.
> 
> (I was able to run the script with error, so for me it was useless)
> 

I think there's more to the story...

>>
>> ~/yocto/build/tmp/work/nitrogen6x-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/image/unit_tests$
>> ls -l *pxp*
>> -rwxr-xr-x 1 ericn ericn 382803 Mar 30 20:34 autorun-pxp.sh
>> -rwxr-xr-x 1 ericn ericn 382803 Mar 30 20:34 pxp_test.out
>> ~/yocto/build/tmp/work/nitrogen6x-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/image/unit_tests$
>> file autorun-pxp.sh
>> autorun-pxp.sh: ELF 32-bit LSB  executable, ARM, EABI5 version 1...
>>
>> Something appears to be broken in the build process, since I do
>> find a script with some sample command-lines in the source tree:
>>

The pxp_v4l2_test.out program isn't part of the package, and the
'pxp_test.out' program wants arguments that are quite different
from this:

>> pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -dst 0:0:352:240 -a 100
>> -w 2 fb-352x240.yuv  BLANK

root@nitrogen6x:/unit_tests# pxp_v4l2_test.out -sx 480 -sy 272 -res
352:240 -dst 0:0:352:240 -a 100 BLANK
./pxp_test.out: invalid option -- 's'
Usage: ./pxp_test.out -I "<options for each instance>" -H display this help

options for each instance
   -o <output file> Write output to file
 	If no output is specified, default is panel
   -r <rotation angle>
   -h <horizontal flip>
   -v <vertical flip>
   -l <left position for display>
   -t <top position for display>
   -i <pixel inversion>

I don't suppose there's an official git repository for this package?

Please advise,


Eric

Re: PXP test applications

[Daiane Angolini]

On Fri, Apr 10, 2015 at 3:32 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> Hi Daiane,
>
> On 04/10/2015 08:58 AM, Daiane Angolini wrote:
>> On Fri, Apr 10, 2015 at 11:47 AM, Eric Nelson
>> <eric.nelson@boundarydevices.com> wrote:
>>> Thanks Daiane,
>>>
>>> On 04/10/2015 05:09 AM, Daiane Angolini wrote:
>>>> On Thu, Apr 9, 2015 at 6:13 PM, Eric Nelson
>>>> <eric.nelson@boundarydevices.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> Does anyone know how to run the pxp_test.out program
>>>>> from /unit_tests?
>>>>>
>>>>> I can run it, but it's not clear what is supposed to happen.
>>>>>
>>>>> root@nitrogen6x:/unit_tests# ./pxp_test.out -H
>>>>> Usage: ./pxp_test.out -I "<options for each instance>" -H display this help
>>>>>
>>>>> options for each instance
>>>>>    -o <output file> Write output to file
>>>>>         If no output is specified, default is panel
>>>>>    -r <rotation angle>
>>>>>    -h <horizontal flip>
>>>>>    -v <vertical flip>
>>>>>    -l <left position for display>
>>>>>    -t <top position for display>
>>>>>    -i <pixel inversion>
>>>>>
>>>>> I can run it, but I'm not sure what it's supposed to do.
>>>>>
>>>>> root@nitrogen6x:/unit_tests# ./pxp_test.out -I "-h -v -l 10 -t 100 -i
>>>>> akiyo.mp4"
>>>>
>>>> If you look under /unit_test folder, you find a pxp_autorun.sh script
>>>> (or something like that)
>>>>
>>>> The autorun* scripts are a set of command lines to run "automatically"
>>>> the *.out test.
>>>>
>>>> Maybe it can help you figure out how to use it
>>>>
>>>
>>> Oddly, the file pxp_autorun.sh isn't a script:
>>
>> I was able to run the script some version in the recent past, so I
>> think it's a regression.
>>
>> (I was able to run the script with error, so for me it was useless)
>>
>
> I think there's more to the story...
>
>>>
>>> ~/yocto/build/tmp/work/nitrogen6x-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/image/unit_tests$
>>> ls -l *pxp*
>>> -rwxr-xr-x 1 ericn ericn 382803 Mar 30 20:34 autorun-pxp.sh
>>> -rwxr-xr-x 1 ericn ericn 382803 Mar 30 20:34 pxp_test.out
>>> ~/yocto/build/tmp/work/nitrogen6x-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/image/unit_tests$
>>> file autorun-pxp.sh
>>> autorun-pxp.sh: ELF 32-bit LSB  executable, ARM, EABI5 version 1...
>>>
>>> Something appears to be broken in the build process, since I do
>>> find a script with some sample command-lines in the source tree:
>>>
>
> The pxp_v4l2_test.out program isn't part of the package, and the
> 'pxp_test.out' program wants arguments that are quite different
> from this:
>
>>> pxp_v4l2_test.out -sx 480 -sy 272 -res 352:240 -dst 0:0:352:240 -a 100
>>> -w 2 fb-352x240.yuv  BLANK
>
> root@nitrogen6x:/unit_tests# pxp_v4l2_test.out -sx 480 -sy 272 -res
> 352:240 -dst 0:0:352:240 -a 100 BLANK
> ./pxp_test.out: invalid option -- 's'
> Usage: ./pxp_test.out -I "<options for each instance>" -H display this help
>
> options for each instance
>    -o <output file> Write output to file
>         If no output is specified, default is panel
>    -r <rotation angle>
>    -h <horizontal flip>
>    -v <vertical flip>
>    -l <left position for display>
>    -t <top position for display>
>    -i <pixel inversion>
>
> I don't suppose there's an official git repository for this package?

The "official repository" is the one inside the package....

There is nothing more I can help, sorry. I also failed on getting it to work.

Daiane
>
> Please advise,
>
>
> Eric

Re: PXP test applications

[Carlos Rafael Giani]

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


> The "official repository" is the one inside the package....
>
> There is nothing more I can help, sorry. I also failed on getting it to work.
>
> Daiane
>

Which is a pity, because PxP seems to be partially broken in the kernel. 
That, or the headers contain a whole lot of formats that will be 
supported in the future, but aren't right now.
A lot of source/destination format combinations produce erroneous 
content, just just plain black or green frames.

I attached the results of my findings. I did the tests with 
gstreamer-imx (current master) , Yocto Fido, kernel linux-imx 
3.14.28-1.0.0_ga+g91cf351 , on a Sabre SD DualLite with integrated 
touchscreen. Plain framebuffer, no X, no Wayland.

The first matrix is the full version - I tried all formats with all 
formats. The second matrix is the one reduced to the subset that works 
best. Unfortunately, BGRx/RGB16 as source and UYVY as target format 
produce reversed colors, otherwise this would be a matrix with all 
combinations working. Also unfortunate is the fact that I420 didn't work 
at all as target format. Since the VPU expects I420 as input for 
encoding, PxP would have been useful as a single conversion step for 
some webcams that deliver Y42B data.

If anybody can make sense about why PxP is so broken, I'd be happy to 
hear about it.

Carlos

[-- Attachment #2: pxp-conv-matrix.txt --]
[-- Type: text/plain, Size: 4941 bytes --]

       RGBx BGRx RGBA BGRA ABGR RGB BGR RGB16 RGB15 GRAY8 YUY2 UYVY YVYU v308 IYU1 I420 YV12 Y42B NV12 NV21 NV16 YUV9 YVU9
RGBx   n    n    n    n    n    n   n   n     n     n     g    g    g    g    g    g    g    g    g    g    g    g    g   
BGRx   n    X    n    X    n    r   n   X     l     X     g    r    g    g    g    g    g    g    g    g    g    g    g
RGBA   n    n    n    n    n    n   n   n     n     n     g    g    g    g    g    g    g    g    g    g    g    g    g
BGRA   n    n    n    n    n    n   n   n     n     n     g    g    g    g    g    g    g    g    g    g    g    g    g
ABGR   n    n    n    n    n    n   n   n     n     n     g    g    g    g    g    g    g    g    g    g    g    g    g
RGB    n    n    n    n    n    n   n   n     n     n     g    g    g    g    g    g    g    g    g    g    g    g    g
BGR    n    n    n    n    n    n   n   n     n     n     g    g    g    g    g    g    g    g    g    g    g    g    g
RGB16  l    X    l    X    l    r   l   X     l     X     g    r    g    g    g    g    g    g    g    g    g    g    g
RGB15  l    v    l    v    l    v   l   v     l     v     g    g    g    g    g    g    g    g    g    g    g    g    g
GRAY8  l    r    l    r    l    r   l   r     l     X     g    r    g    g    g    g    g    g    g    g    g    g    g
YUY2   l    X    l    X    l    r   l   X     l     X     g    X    g    g    g    g    g    g    g    g    g    g    g
UYVY   l    X    l    X    l    r   l   X     l     X     g    X    g    g    g    g    g    g    g    g    g    g    g
YVYU   l    X    l    X    l    r   l   X     l     X     g    X    g    g    g    g    g    g    g    g    g    g    g
v308   l    c    l    c    l    c   l   c     l     c     g    c    g    g    g    g    g    g    g    g    g    g    g
IYU1   l    g    l    g    l    g   l   g     l     n     g    g    g    g    g    g    g    g    g    g    g    g    g
I420   l    X    l    X    l    r   l   X     l     X     g    X    g    g    g    g    g    g    g    g    g    g    g
YV12   l    X    l    X    l    r   l   X     l     X     g    X    g    g    g    g    g    g    g    g    g    g    g
Y42B   l    X    l    X    l    r   l   X     l     X     g    X    g    g    g    g    g    g    g    g    g    g    g
NV12   l    X    l    X    l    r   l   X     l     X     g    X    g    g    g    g    g    g    g    g    g    g    g
NV21   l    r    l    r    l    r   l   r     l     r     l    r    g    g    g    g    g    g    g    g    g    g    g
NV16   l    f    l    f    l    t   l   f     l     X     l    f    g    g    g    g    g    g    g    g    g    g    g
YUV9   l    g    l    g    l    g   l   g     l     n     g    g    g    g    g    g    g    g    g    g    g    g    g
YVU9   l    g    l    g    l    g   l   g     l     n     g    g    g    g    g    g    g    g    g    g    g    g    g



test pipeline:
gst-launch-1.0 videotestsrc pattern=smpte ! "video/x-raw, format=BGRx" ! videoconvert dither=0 ! "video/x-raw, format=<SRCFORMAT>" ! imxpxpvideotransform ! "video/x-raw, format=<DESTFORMAT>" ! videoconvert dither=0 ! "video/x-raw, format=BGRx" ! imxg2dvideosink

reference pipeline:
gst-launch-1.0 videotestsrc pattern=smpte ! "video/x-raw, format=BGRx" ! videoconvert dither=0 ! "video/x-raw, format=<SRCFORMAT>" ! videoconvert dither=0 ! "video/x-raw, format=<DESTFORMAT>" ! videoconvert dither=0 ! "video/x-raw, format=BGRx" ! imxg2dvideosink

The reference pipeline converts all formats properly.


left column : source format (<SRCFORMAT>)
top row : destination format (<DESTFORMAT>)
examples:
  BGRx -> BGRA = X
  GRAY8 -> RGB = r


n = nothing (black)
g = green screen
X = okay
r = colors reversed
l = only one scan line at the top, rest black
v = first scanline is repeated all the way to the bottom of the screen
c = frameirecognizable, but corrupted
f = left half OK, right half color-corrupted
t = left half color reversed, right half color-corrupted



=== Reduced version ===

removed source formats: RGBx RGBA BGRA ABGR RGB BGR GRAY8[1] RGB15[2] v308[3] IYU1 NV21[4] NV16[5] YUV9 YVU9
[1] : spread like the others, but all colors were wrong except for the GRAY8->GRAY8 case
[2] : first scanline is repeated all the way to the bottom of the screen
[3] : screen corrupted
[4] : colors reversed ; perhaps improper PxP usage?
[5] : half ok, half colors corrupted ; perhaps improper PxP usage?

removed destination formats: RGBx BGRA ARGB RGB[6] BGR RGB15 YUY2 YVYU v308 IYU1 I420 YV12 Y42B NV12 NV21 NV16 YUV9 YVU9
[6] : r<->b reversed

       BGRx BGRA RGB16 GRAY8 UYVY
BGRx   X    X    X     X     r
RGB16  X    X    X     X     r
YUY2   X    X    X     X     X
UYVY   X    X    X     X     X
YVYU   X    X    X     X     X
I420   X    X    X     X     X
YV12   X    X    X     X     X
Y42B   X    X    X     X     X
NV12   X    X    X     X     X

Re: PXP test applications

[Eric Nelson]

Hi Carlos,

On 04/11/2015 09:30 AM, Carlos Rafael Giani wrote:
> 
>> The "official repository" is the one inside the package....
>>
>> There is nothing more I can help, sorry. I also failed on getting it
>> to work.
>>
>> Daiane
>>
> 
> Which is a pity, because PxP seems to be partially broken in the kernel.
> That, or the headers contain a whole lot of formats that will be
> supported in the future, but aren't right now.
> A lot of source/destination format combinations produce erroneous
> content, just just plain black or green frames.
> 
> I attached the results of my findings. I did the tests with
> gstreamer-imx (current master) , Yocto Fido, kernel linux-imx
> 3.14.28-1.0.0_ga+g91cf351 , on a Sabre SD DualLite with integrated
> touchscreen. Plain framebuffer, no X, no Wayland.
> 
> The first matrix is the full version - I tried all formats with all
> formats. The second matrix is the one reduced to the subset that works
> best. Unfortunately, BGRx/RGB16 as source and UYVY as target format
> produce reversed colors, otherwise this would be a matrix with all
> combinations working. Also unfortunate is the fact that I420 didn't work
> at all as target format. Since the VPU expects I420 as input for
> encoding, PxP would have been useful as a single conversion step for
> some webcams that deliver Y42B data.
> 
> If anybody can make sense about why PxP is so broken, I'd be happy to
> hear about it.
> 

I can't comment on the state of the driver(s), but I can comment
on your tests and say "thanks"!

This e-mail should be bookmarked by anyone visiting the driver.

I hope we can test this out soon, but think it will have to wait
until we push forward to 3.14.28.

Regards,


Eric