[meta-freescale] 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 at mail.bg
>>>> <mailto:picmaster at 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 at 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