From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 4B47BE009E1; Mon, 25 May 2015 07:24:43 -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.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -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 EB5DAE009B8 for ; Mon, 25 May 2015 07:24:37 -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 3DDCE600158E for ; Mon, 25 May 2015 17:24:36 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1432563876; bh=ceRd0DyeCDuQYMyxPAsTdj5pV1OIJ4FXDt1iV7chTjw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kBvlfs4WAbIMMoDgJKXmVqVfDPRlvzWmiZsttxNgGJcNrtkGG2mWZ7ApULCpcVIAh Uwj8jKA9BUR9KUkaxZ5wbFgVkq6y2qwLzoPiYvDWOjMHwXo/zrhkbIBFVTL7NcKYDl p6BG41iS/onNuNz/Ai9UjJ+eyUUn2RGLs2RevFoA= Message-ID: <556330A4.4010009@mail.bg> Date: Mon, 25 May 2015 17:24:36 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.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> <555E892B.1010904@mail.bg> In-Reply-To: <555E892B.1010904@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: Mon, 25 May 2015 14:24:43 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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