From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 53957E009C8; Thu, 21 May 2015 18:41:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id A3B85E00974 for ; Thu, 21 May 2015 18:41:00 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id B17816000A3D for ; Fri, 22 May 2015 04:40:59 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1432258859; bh=n9F23y1GH+rXUvG69hLPr2txRH1BtUOD64FuI0GFmOI=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=1tuDuCYM8wK+UDpWBIH8GcTzr343MzFhWfa/N+BcPB5wVv8VLI/fO7vYW7ze4twBf /JYTFcUA+j0fTXL9HnbZkfjuH69ivq9yAuw0nC8ZA+sjXvPZVCga7drzDoy1Y8hmwk fH4359vODgO1MJL6onRglD69QIS3sH180tQ6vxvU= Message-ID: <555E892B.1010904@mail.bg> Date: Fri, 22 May 2015 04:40:59 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: "meta-freescale@yoctoproject.org" References: <555B61DF.2000903@mail.bg> <555CC752.6060706@mail.bg> <555D1C21.6020402@mail.bg> <555D3C7D.7020406@mail.bg> In-Reply-To: <555D3C7D.7020406@mail.bg> Subject: Re: Video overlay on sabresd X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 01:41:04 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 >>> > 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