Video overlay on sabresd

Video overlay on sabresd

[Nikolay Dimitrov]

Hi guys,

I'm trying to get the video overlay working on imx6q sabresd's HDMI.
Here's the kernel command line:

console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw 
video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB2
4,bpp=32 fbmem=28M

This is the kernel version:

# uname -a
Linux imx6qsabresd 3.14.28-1.0.0_ga+g91cf351 #1 SMP PREEMPT Tue May 19 
17:32:51 EEST 2015 armv7l
GNU/Linux

Here are the framebuffer devices nodes:

# ls -lh /dev/fb*
crw-rw----    1 root     video      29,   0 Jan  1  1970 /dev/fb0
crw-rw----    1 root     video      29,   1 Jan  1  1970 /dev/fb1
crw-rw----    1 root     video      29,   2 Jan  1  1970 /dev/fb2
crw-rw----    1 root     video      29,   3 Jan  1  1970 /dev/fb3

I can write arbitrary data on /dev/fb0 and see it on screen, like this:

# cat /bin/busybox.nosuid > /dev/fb0

But I can't write to /dev/fb1:

# cat /bin/busybox.nosuid > /dev/fb1
cat: write error: No space left on device

I'm assuming that fb0 is the background layer, and fb1 is the
foreground IPU layer.

So the question is - how to make the foreground (fb1) layer working at
all? Should I configure mxcfb1 in the bootargs, or it needs some IOCTL
in /dev/fb1 to enable the device?

Thanks in advance. Regards,
Nikolay

Re: Video overlay on sabresd

[Prabhu S]

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

How about this?
/unit_tests/mxc_v4l2_output.out -iw 1024 -ih 768 -ow 1024 -oh 768 -d
/dev/video17 -fr 30 -l 10 -f YUYV ./your-file.yuyv

/dev/video17 is for overlay

On Tue, May 19, 2015 at 11:16 AM, Nikolay Dimitrov <picmaster@mail.bg>
wrote:

> Hi guys,
>
> I'm trying to get the video overlay working on imx6q sabresd's HDMI.
> Here's the kernel command line:
>
> console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw
> video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB2
> 4,bpp=32 fbmem=28M
>
> This is the kernel version:
>
> # uname -a
> Linux imx6qsabresd 3.14.28-1.0.0_ga+g91cf351 #1 SMP PREEMPT Tue May 19
> 17:32:51 EEST 2015 armv7l
> GNU/Linux
>
> Here are the framebuffer devices nodes:
>
> # ls -lh /dev/fb*
> crw-rw----    1 root     video      29,   0 Jan  1  1970 /dev/fb0
> crw-rw----    1 root     video      29,   1 Jan  1  1970 /dev/fb1
> crw-rw----    1 root     video      29,   2 Jan  1  1970 /dev/fb2
> crw-rw----    1 root     video      29,   3 Jan  1  1970 /dev/fb3
>
> I can write arbitrary data on /dev/fb0 and see it on screen, like this:
>
> # cat /bin/busybox.nosuid > /dev/fb0
>
> But I can't write to /dev/fb1:
>
> # cat /bin/busybox.nosuid > /dev/fb1
> cat: write error: No space left on device
>
> I'm assuming that fb0 is the background layer, and fb1 is the
> foreground IPU layer.
>
> So the question is - how to make the foreground (fb1) layer working at
> all? Should I configure mxcfb1 in the bootargs, or it needs some IOCTL
> in /dev/fb1 to enable the device?
>
> Thanks in advance. Regards,
> Nikolay
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

[-- Attachment #2: Type: text/html, Size: 2461 bytes --]

Re: Video overlay on sabresd

[Nikolay Dimitrov]

Hi Prabhu,

On 05/19/2015 07:22 PM, Prabhu S wrote:
> How about this?
> /unit_tests/mxc_v4l2_output.out -iw 1024 -ih 768 -ow 1024 -oh 768 -d
> /dev/video17 -fr 30 -l 10 -f YUYV ./your-file.yuyv
>
> /dev/video17 is for overlay
>
> On Tue, May 19, 2015 at 11:16 AM, Nikolay Dimitrov <picmaster@mail.bg
> <mailto:picmaster@mail.bg>> wrote:
>
>     Hi guys,
>
>     I'm trying to get the video overlay working on imx6q sabresd's HDMI.
>     Here's the kernel command line:
>
>     console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw
>     video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB2
>     4,bpp=32 fbmem=28M
>
>     This is the kernel version:
>
>     # uname -a
>     Linux imx6qsabresd 3.14.28-1.0.0_ga+g91cf351 #1 SMP PREEMPT Tue May
>     19 17:32:51 EEST 2015 armv7l
>     GNU/Linux
>
>     Here are the framebuffer devices nodes:
>
>     # ls -lh /dev/fb*
>     crw-rw----    1 root     video      29,   0 Jan  1  1970 /dev/fb0
>     crw-rw----    1 root     video      29,   1 Jan  1  1970 /dev/fb1
>     crw-rw----    1 root     video      29,   2 Jan  1  1970 /dev/fb2
>     crw-rw----    1 root     video      29,   3 Jan  1  1970 /dev/fb3
>
>     I can write arbitrary data on /dev/fb0 and see it on screen, like this:
>
>     # cat /bin/busybox.nosuid > /dev/fb0
>
>     But I can't write to /dev/fb1:
>
>     # cat /bin/busybox.nosuid > /dev/fb1
>     cat: write error: No space left on device
>
>     I'm assuming that fb0 is the background layer, and fb1 is the
>     foreground IPU layer.
>
>     So the question is - how to make the foreground (fb1) layer working at
>     all? Should I configure mxcfb1 in the bootargs, or it needs some IOCTL
>     in /dev/fb1 to enable the device?

Thanks for sharing. This works, but I'm trying to achieve exactly the
opposite.

I need to have my UI on the FG layer (which imho means X rendering to
/dev/fb1), and my video player must render on BG layer (/dev/video16,
which imho corresponds to /dev/fb0).

At the moment I can't seem to be able to draw anything on /dev/fb1, so
I doubt that Xorg will also run properly on it.

Regards,
Nikolay

Re: Video overlay on sabresd

[Nikolay Dimitrov]

Hi all,

On 05/20/2015 08:41 PM, Nikolay Dimitrov wrote:
> Hi Prabhu,
>
> On 05/19/2015 07:22 PM, Prabhu S wrote:
>> How about this?
>> /unit_tests/mxc_v4l2_output.out -iw 1024 -ih 768 -ow 1024 -oh 768 -d
>> /dev/video17 -fr 30 -l 10 -f YUYV ./your-file.yuyv
>>
>> /dev/video17 is for overlay
>>
>> On Tue, May 19, 2015 at 11:16 AM, Nikolay Dimitrov <picmaster@mail.bg
>> <mailto:picmaster@mail.bg>> wrote:
>>
>>     Hi guys,
>>
>>     I'm trying to get the video overlay working on imx6q sabresd's HDMI.
>>     Here's the kernel command line:
>>
>>     console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw
>>     video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB2
>>     4,bpp=32 fbmem=28M
>>
>>     This is the kernel version:
>>
>>     # uname -a
>>     Linux imx6qsabresd 3.14.28-1.0.0_ga+g91cf351 #1 SMP PREEMPT Tue May
>>     19 17:32:51 EEST 2015 armv7l
>>     GNU/Linux
>>
>>     Here are the framebuffer devices nodes:
>>
>>     # ls -lh /dev/fb*
>>     crw-rw----    1 root     video      29,   0 Jan  1  1970 /dev/fb0
>>     crw-rw----    1 root     video      29,   1 Jan  1  1970 /dev/fb1
>>     crw-rw----    1 root     video      29,   2 Jan  1  1970 /dev/fb2
>>     crw-rw----    1 root     video      29,   3 Jan  1  1970 /dev/fb3
>>
>>     I can write arbitrary data on /dev/fb0 and see it on screen, like
>> this:
>>
>>     # cat /bin/busybox.nosuid > /dev/fb0
>>
>>     But I can't write to /dev/fb1:
>>
>>     # cat /bin/busybox.nosuid > /dev/fb1
>>     cat: write error: No space left on device
>>
>>     I'm assuming that fb0 is the background layer, and fb1 is the
>>     foreground IPU layer.
>>
>>     So the question is - how to make the foreground (fb1) layer
>> working at
>>     all? Should I configure mxcfb1 in the bootargs, or it needs some
>> IOCTL
>>     in /dev/fb1 to enable the device?
>
> Thanks for sharing. This works, but I'm trying to achieve exactly the
> opposite.
>
> I need to have my UI on the FG layer (which imho means X rendering to
> /dev/fb1), and my video player must render on BG layer (/dev/video16,
> which imho corresponds to /dev/fb0).
>
> At the moment I can't seem to be able to draw anything on /dev/fb1, so
> I doubt that Xorg will also run properly on it.

I've reordered the video interfaces in the DT, and also in the kernel
cmdline, to make sure the hdmi is the first and only video interface,
so hopefully the IPU driver will create both BG and FG channels for it.

Unfortunately I still can't write to /dev/fb1, so I'm digging further.

Regards,
Nikolay

Re: Video overlay on sabresd

[Nikolay Dimitrov]

Hi all,

On 05/21/2015 02:43 AM, Nikolay Dimitrov wrote:
> Hi all,
>
> On 05/20/2015 08:41 PM, Nikolay Dimitrov wrote:
>> Hi Prabhu,
>>
>> On 05/19/2015 07:22 PM, Prabhu S wrote:
>>> How about this?
>>> /unit_tests/mxc_v4l2_output.out -iw 1024 -ih 768 -ow 1024 -oh 768 -d
>>> /dev/video17 -fr 30 -l 10 -f YUYV ./your-file.yuyv
>>>
>>> /dev/video17 is for overlay
>>>
>>> On Tue, May 19, 2015 at 11:16 AM, Nikolay Dimitrov <picmaster@mail.bg
>>> <mailto:picmaster@mail.bg>> wrote:
>>>
>>>     Hi guys,
>>>
>>>     I'm trying to get the video overlay working on imx6q sabresd's HDMI.
>>>     Here's the kernel command line:
>>>
>>>     console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw
>>>     video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB2
>>>     4,bpp=32 fbmem=28M
>>>
>>>     This is the kernel version:
>>>
>>>     # uname -a
>>>     Linux imx6qsabresd 3.14.28-1.0.0_ga+g91cf351 #1 SMP PREEMPT Tue May
>>>     19 17:32:51 EEST 2015 armv7l
>>>     GNU/Linux
>>>
>>>     Here are the framebuffer devices nodes:
>>>
>>>     # ls -lh /dev/fb*
>>>     crw-rw----    1 root     video      29,   0 Jan  1  1970 /dev/fb0
>>>     crw-rw----    1 root     video      29,   1 Jan  1  1970 /dev/fb1
>>>     crw-rw----    1 root     video      29,   2 Jan  1  1970 /dev/fb2
>>>     crw-rw----    1 root     video      29,   3 Jan  1  1970 /dev/fb3
>>>
>>>     I can write arbitrary data on /dev/fb0 and see it on screen, like
>>> this:
>>>
>>>     # cat /bin/busybox.nosuid > /dev/fb0
>>>
>>>     But I can't write to /dev/fb1:
>>>
>>>     # cat /bin/busybox.nosuid > /dev/fb1
>>>     cat: write error: No space left on device
>>>
>>>     I'm assuming that fb0 is the background layer, and fb1 is the
>>>     foreground IPU layer.
>>>
>>>     So the question is - how to make the foreground (fb1) layer
>>> working at
>>>     all? Should I configure mxcfb1 in the bootargs, or it needs some
>>> IOCTL
>>>     in /dev/fb1 to enable the device?
>>
>> Thanks for sharing. This works, but I'm trying to achieve exactly the
>> opposite.
>>
>> I need to have my UI on the FG layer (which imho means X rendering to
>> /dev/fb1), and my video player must render on BG layer (/dev/video16,
>> which imho corresponds to /dev/fb0).
>>
>> At the moment I can't seem to be able to draw anything on /dev/fb1, so
>> I doubt that Xorg will also run properly on it.
>
> I've reordered the video interfaces in the DT, and also in the kernel
> cmdline, to make sure the hdmi is the first and only video interface,
> so hopefully the IPU driver will create both BG and FG channels for it.
>
> Unfortunately I still can't write to /dev/fb1, so I'm digging further.

Prabhu's comment hinted me to start looking around /unit_tests and
if/how they work. It turned out that the mxc_fb_test application worked
somewhat and I was able observe alpha-blending between FG & BG layers.

Then, after some more head-banging, the issue where I couldn't write to
the framebuffer was resolved by this:

echo 0 > /sys/class/graphics/fb1/blank

Much nicer! Now I can go and test how Xorg works on /dev/fb1, but it's
probably a better idea to get some sleep before this...

Regards,
Nikolay

Re: Video overlay on sabresd

[Nikolay Dimitrov]

Hi gang,

On 05/21/2015 05:01 AM, Nikolay Dimitrov wrote:
> Hi all,
>
> On 05/21/2015 02:43 AM, Nikolay Dimitrov wrote:
>> Hi all,
>>
>> On 05/20/2015 08:41 PM, Nikolay Dimitrov wrote:
>>> Hi Prabhu,
>>>
>>> On 05/19/2015 07:22 PM, Prabhu S wrote:
>>>> How about this?
>>>> /unit_tests/mxc_v4l2_output.out -iw 1024 -ih 768 -ow 1024 -oh 768 -d
>>>> /dev/video17 -fr 30 -l 10 -f YUYV ./your-file.yuyv
>>>>
>>>> /dev/video17 is for overlay
>>>>
>>>> On Tue, May 19, 2015 at 11:16 AM, Nikolay Dimitrov <picmaster@mail.bg
>>>> <mailto:picmaster@mail.bg>> wrote:
>>>>
>>>>     Hi guys,
>>>>
>>>>     I'm trying to get the video overlay working on imx6q sabresd's
>>>> HDMI.
>>>>     Here's the kernel command line:
>>>>
>>>>     console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw
>>>>     video=mxcfb0:dev=hdmi,1280x720M@60,if=RGB2
>>>>     4,bpp=32 fbmem=28M
>>>>
>>>>     This is the kernel version:
>>>>
>>>>     # uname -a
>>>>     Linux imx6qsabresd 3.14.28-1.0.0_ga+g91cf351 #1 SMP PREEMPT Tue May
>>>>     19 17:32:51 EEST 2015 armv7l
>>>>     GNU/Linux
>>>>
>>>>     Here are the framebuffer devices nodes:
>>>>
>>>>     # ls -lh /dev/fb*
>>>>     crw-rw----    1 root     video      29,   0 Jan  1  1970 /dev/fb0
>>>>     crw-rw----    1 root     video      29,   1 Jan  1  1970 /dev/fb1
>>>>     crw-rw----    1 root     video      29,   2 Jan  1  1970 /dev/fb2
>>>>     crw-rw----    1 root     video      29,   3 Jan  1  1970 /dev/fb3
>>>>
>>>>     I can write arbitrary data on /dev/fb0 and see it on screen, like
>>>> this:
>>>>
>>>>     # cat /bin/busybox.nosuid > /dev/fb0
>>>>
>>>>     But I can't write to /dev/fb1:
>>>>
>>>>     # cat /bin/busybox.nosuid > /dev/fb1
>>>>     cat: write error: No space left on device
>>>>
>>>>     I'm assuming that fb0 is the background layer, and fb1 is the
>>>>     foreground IPU layer.
>>>>
>>>>     So the question is - how to make the foreground (fb1) layer
>>>> working at
>>>>     all? Should I configure mxcfb1 in the bootargs, or it needs some
>>>> IOCTL
>>>>     in /dev/fb1 to enable the device?
>>>
>>> Thanks for sharing. This works, but I'm trying to achieve exactly the
>>> opposite.
>>>
>>> I need to have my UI on the FG layer (which imho means X rendering to
>>> /dev/fb1), and my video player must render on BG layer (/dev/video16,
>>> which imho corresponds to /dev/fb0).
>>>
>>> At the moment I can't seem to be able to draw anything on /dev/fb1, so
>>> I doubt that Xorg will also run properly on it.
>>
>> I've reordered the video interfaces in the DT, and also in the kernel
>> cmdline, to make sure the hdmi is the first and only video interface,
>> so hopefully the IPU driver will create both BG and FG channels for it.
>>
>> Unfortunately I still can't write to /dev/fb1, so I'm digging further.
>
> Prabhu's comment hinted me to start looking around /unit_tests and
> if/how they work. It turned out that the mxc_fb_test application worked
> somewhat and I was able observe alpha-blending between FG & BG layers.
>
> Then, after some more head-banging, the issue where I couldn't write to
> the framebuffer was resolved by this:
>
> echo 0 > /sys/class/graphics/fb1/blank
>
> Much nicer! Now I can go and test how Xorg works on /dev/fb1, but it's
> probably a better idea to get some sleep before this...

Xorg works on /dev/fb1. But...

- Resolution: the foreground framebuffer resolution is hard-coded in
the kernel driver to 240x320, and no "magic words" were able to
convince Xorg to change the resolution to 1280x720. It's possible to
add additional video modes in runtime by using xrandr in Xorg init
scripts, but this is a hairy hack, I would prefer the FG layer to have
the same resolution as the BG layer.

- Color depth: again hard-coded to 16bpp, don't know how to change
this. The fun part is that at the same time the BG layer has 32bpp
color depth.

- Chroma keying is buggy: opening the V4L2 device file (/dev/video16)
on the BG layer resets the chroma key. Here are steps to reproduce:

1. Start Xorg on /dev/fb1.
2. Start a X11 app, which draws a solid-colored rectangle containing
the chroma key (0xFF00FF in my case).
3. Run a console app, which programs the chroma key to 0xFF00FF and
global alpha to 0x80.
4. Observe that the chroma-key colored rectangle is now
fully transparent, as expected.
5. Start gstreamer with imxv4l2sink, using /dev/video16
6. Observe that chroma-key colored rectangle is opaque. This is an
issue.

If #3 is executed while the video is playing, the colored rectangle
becomes fully transparent, as expected.

Regards,
Nikolay

Re: Video overlay on sabresd

[Marco Trillo]

Hi,

On 05/22/2015 03:40 AM, Nikolay Dimitrov wrote:
>>>> Thanks for sharing. This works, but I'm trying to achieve exactly the
>>>> opposite.
>>>>
>>>> I need to have my UI on the FG layer (which imho means X rendering to
>>>> /dev/fb1), and my video player must render on BG layer (/dev/video16,
>>>> which imho corresponds to /dev/fb0).
Actually you should be able to achieve what you want by using either one 
of the MXCFB_SET_GBL_ALPHA, MXCFB_SET_LOC_ALPHA or MXCFB_SET_OVERLAY_POS 
ioctls on /dev/fb0, so that this layer renders atop the /dev/video17 at 
/dev/fb1 (with a global alpha with the first one, or a pixel-based alpha 
with the second one which needs 32bpp).


> - Chroma keying is buggy: opening the V4L2 device file (/dev/video16)
> on the BG layer resets the chroma key. Here are steps to reproduce:
>
> 1. Start Xorg on /dev/fb1.
> 2. Start a X11 app, which draws a solid-colored rectangle containing
> the chroma key (0xFF00FF in my case).
> 3. Run a console app, which programs the chroma key to 0xFF00FF and
> global alpha to 0x80.
> 4. Observe that the chroma-key colored rectangle is now
> fully transparent, as expected.
> 5. Start gstreamer with imxv4l2sink, using /dev/video16
> 6. Observe that chroma-key colored rectangle is opaque. This is an
> issue.
>
> If #3 is executed while the video is playing, the colored rectangle
> becomes fully transparent, as expected.

I think this is more an issue with the `imxv4l2sink' plug-in, which 
resets the global alpha of the layer, than the /dev/video* node itself. 
Unfortunately, the `imxv4l2sink' plug-in seems to be written so that it 
manages the layers itself, containing incomplete code for setting the 
global alpha, the local alpha, and the color key, but not fully exposing 
these options via gstreamer properties. You may want to try the sink 
based on the IPU lib directly (`mfw_isink' IIRC) and see how it behaves.

Kind regards
Marco

Re: Video overlay on sabresd

[Nikolay Dimitrov]

Hi Marco,

On 05/25/2015 10:47 AM, Marco Trillo wrote:
> Hi,
>
> On 05/22/2015 03:40 AM, Nikolay Dimitrov wrote:
>>>>> Thanks for sharing. This works, but I'm trying to achieve exactly the
>>>>> opposite.
>>>>>
>>>>> I need to have my UI on the FG layer (which imho means X rendering to
>>>>> /dev/fb1), and my video player must render on BG layer (/dev/video16,
>>>>> which imho corresponds to /dev/fb0).
> Actually you should be able to achieve what you want by using either one
> of the MXCFB_SET_GBL_ALPHA, MXCFB_SET_LOC_ALPHA or MXCFB_SET_OVERLAY_POS
> ioctls on /dev/fb0, so that this layer renders atop the /dev/video17 at
> /dev/fb1 (with a global alpha with the first one, or a pixel-based alpha
> with the second one which needs 32bpp).

Exactly. Regarding the MXCFB_SET_OVERLAY_POS - I was thinking this
ioctl is related to X/Y position of the layer and not about the layers'
Z-order (at least this is the impression I have looking at the mxcfb
driver and imx lib code). Please correct me if I'm wrong, but I thing
the Z-order of the BG/FG IPU layers is not programmable.

>> - Chroma keying is buggy: opening the V4L2 device file (/dev/video16)
>> on the BG layer resets the chroma key. Here are steps to reproduce:
>>
>> 1. Start Xorg on /dev/fb1.
>> 2. Start a X11 app, which draws a solid-colored rectangle containing
>> the chroma key (0xFF00FF in my case).
>> 3. Run a console app, which programs the chroma key to 0xFF00FF and
>> global alpha to 0x80.
>> 4. Observe that the chroma-key colored rectangle is now
>> fully transparent, as expected.
>> 5. Start gstreamer with imxv4l2sink, using /dev/video16
>> 6. Observe that chroma-key colored rectangle is opaque. This is an
>> issue.
>>
>> If #3 is executed while the video is playing, the colored rectangle
>> becomes fully transparent, as expected.
>
> I think this is more an issue with the `imxv4l2sink' plug-in, which
> resets the global alpha of the layer, than the /dev/video* node itself.
> Unfortunately, the `imxv4l2sink' plug-in seems to be written so that it
> manages the layers itself, containing incomplete code for setting the
> global alpha, the local alpha, and the color key, but not fully exposing
> these options via gstreamer properties. You may want to try the sink
> based on the IPU lib directly (`mfw_isink' IIRC) and see how it behaves.

Yes, I was also thinking along the same lines that the issue could be
caused by several things (xorg, video sink). I'll look around and
probably I can fix this in the gst plugin. Btw, I'm using the V4L2 sink
because in the past I had performance issues when the screen was
rotated at 180 degrees, and the V4L2 performed much better in both 0
and 180 degrees. But I'll definitely try it out.

Regards,
Nikolay

Re: Video overlay on sabresd

[Marco Trillo]

Hi,

On 05/25/2015 11:27 AM, Nikolay Dimitrov wrote:
> Exactly. Regarding the MXCFB_SET_OVERLAY_POS - I was thinking this
> ioctl is related to X/Y position of the layer and not about the layers'
> Z-order (at least this is the impression I have looking at the mxcfb
> driver and imx lib code). Please correct me if I'm wrong, but I thing
> the Z-order of the BG/FG IPU layers is not programmable.

Issuing the MXCFB_SET_GBL_ALPHA or MXCFB_SET_LOC_ALPHA ioctls() at 
/dev/fb0 should cause the `fb0' layer to display atop the `fb1' or video 
layer, mixed according to the global or per-pixel alpha value. This is 
what the docs say (which is a bit confusing):

3.2.2 DP global alpha combination
To enable DP global alpha combination feature, we need to use fb ioctl 
MXCFB_SET_LOC_ALPHA [sic]. [...] By default, /dev/fb0 stands for the 
background frame buffer and /dev/fb2 stands for the foreground frame 
buffer [...] If the open file descriptor of /dev/fb0 is passed to this 
ioctl, the graphics plane of DP is set to the background plane, 
otherwise, the graphics plane is set to the foreground plane.
(from Freescale's "Image Processing Unit V3 (IPUV3) Library User's Guide")

After configuring the DP via these ioctls, you can then use the 
MXCFB_SET_CLR_KEY if you need to use color keying.

Kind regards
Marco

Re: Video overlay on sabresd

[Nikolay Dimitrov]

Hi Marco,

On 05/25/2015 04:22 PM, Marco Trillo wrote:
> Hi,
>
> On 05/25/2015 11:27 AM, Nikolay Dimitrov wrote:
>> Exactly. Regarding the MXCFB_SET_OVERLAY_POS - I was thinking this
>> ioctl is related to X/Y position of the layer and not about the layers'
>> Z-order (at least this is the impression I have looking at the mxcfb
>> driver and imx lib code). Please correct me if I'm wrong, but I thing
>> the Z-order of the BG/FG IPU layers is not programmable.
>
> Issuing the MXCFB_SET_GBL_ALPHA or MXCFB_SET_LOC_ALPHA ioctls() at
> /dev/fb0 should cause the `fb0' layer to display atop the `fb1' or video
> layer, mixed according to the global or per-pixel alpha value. This is
> what the docs say (which is a bit confusing):
>
> 3.2.2 DP global alpha combination
> To enable DP global alpha combination feature, we need to use fb ioctl
> MXCFB_SET_LOC_ALPHA [sic]. [...] By default, /dev/fb0 stands for the
> background frame buffer and /dev/fb2 stands for the foreground frame
> buffer [...] If the open file descriptor of /dev/fb0 is passed to this
> ioctl, the graphics plane of DP is set to the background plane,
> otherwise, the graphics plane is set to the foreground plane.
> (from Freescale's "Image Processing Unit V3 (IPUV3) Library User's Guide")
>
> After configuring the DP via these ioctls, you can then use the
> MXCFB_SET_CLR_KEY if you need to use color keying.

Well, my experiments are showing somewhat different behavior: setting
alpha on fb0 causes color key not to work on fb1. Alpha needs to be
explicitly set to the FG layer (fb1) in order color key to work.

Regards,
Nikolay

Re: Video overlay on sabresd

[Nikolay Dimitrov]

Hi gang,

On 05/22/2015 04:40 AM, Nikolay Dimitrov wrote:
>
> Xorg works on /dev/fb1. But...
>
> - Resolution: the foreground framebuffer resolution is hard-coded in
> the kernel driver to 240x320, and no "magic words" were able to
> convince Xorg to change the resolution to 1280x720. It's possible to
> add additional video modes in runtime by using xrandr in Xorg init
> scripts, but this is a hairy hack, I would prefer the FG layer to have
> the same resolution as the BG layer.

One unpleasant side of the hairy xrender hack is that although it
changes the Xorg resolution, the original mode (240x320) is still
available and causes font issues with Chromium (tab titles and status
messages are displayed with much larger font than usual).

> - Color depth: again hard-coded to 16bpp, don't know how to change
> this. The fun part is that at the same time the BG layer has 32bpp
> color depth.
>
> - Chroma keying is buggy: opening the V4L2 device file (/dev/video16)
> on the BG layer resets the chroma key. Here are steps to reproduce:
>
> 1. Start Xorg on /dev/fb1.
> 2. Start a X11 app, which draws a solid-colored rectangle containing
> the chroma key (0xFF00FF in my case).
> 3. Run a console app, which programs the chroma key to 0xFF00FF and
> global alpha to 0x80.
> 4. Observe that the chroma-key colored rectangle is now
> fully transparent, as expected.
> 5. Start gstreamer with imxv4l2sink, using /dev/video16
> 6. Observe that chroma-key colored rectangle is opaque. This is an
> issue.
>
> If #3 is executed while the video is playing, the colored rectangle
> becomes fully transparent, as expected.

There's one more issue with /dev/fb1 - right after the board boots and
Xorg is started, there's already default alpha value applied to the FG
layer (/dev/fb1), which causes a dim image. Setting global alpha to
0xFF (opaque) fixes the issue.

Regards,
Nikolay