From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id D7182E008C3; Thu, 13 Nov 2014 07:18:02 -0800 (PST) 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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [193.201.172.117 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 mx1.mail.bg (mx1.mail.bg [193.201.172.117]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 5CC43E00831 for ; Thu, 13 Nov 2014 07:17:57 -0800 (PST) Received: from [192.168.0.41] (unknown [93.152.132.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.mail.bg (Postfix) with ESMTPSA id 76CFF6000CF4; Thu, 13 Nov 2014 17:17:56 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1415891876; bh=snEVl3PyqownwlCm6L5d4+J+D7/fVz4P6kj2evcQGm8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JdXcY15HjDo7XOKOB83M79DK1XcVALsXe8qIIGMz92kHKoABnnW/0KjIgiF5HaLRa TUGDXc4zFNM3AO0nm76HO/tgLGs/SZ4FjVIHkmUlS6wqT7oxLnHGb4ICggeV7l3IbS E4ihTsO6rnpj0+4axGplTMPk0PJHymLUGsy32GuI= Message-ID: <5464CB9A.8040000@mail.bg> Date: Thu, 13 Nov 2014 17:17:46 +0200 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: =?UTF-8?B?QW5kcmVhcyBNw7xsbGVy?= References: <5463E620.70400@mail.bg> In-Reply-To: Cc: "meta-freescale@yoctoproject.org" Subject: Re: No HDMI video on imx6qsabresd with dizzy 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: Thu, 13 Nov 2014 15:18:02 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andreas, On 11/13/2014 11:29 AM, Andreas Müller wrote: > On Wed, Nov 12, 2014 at 11:58 PM, Nikolay Dimitrov wrote: >> Hi guys, >> >> I'm trying to use unmodified dizzy build with imx6q sabresd, for >> testing video playback. U-Boot outputs HDMI image during boot, but in >> Linux there's no HDMI image (no console, no video playback). >> >> The image is "fsl-image-multimedia-full", kernel 3.10.17. The device >> files /dev/video* and /dev/fb* are available, but gstreamer playback >> doesn't output any image on the HDMI port (seems to be stuck instead of >> playing). >> >> The kernel cmdline doesn't specify any video settings, which typically >> is an issue, but when I add the video bootargs: >> >> ...video=mxcfb0:dev=hdmi,1024x768M@60,if=RGB24... >> >> The board stops to print any boot messages after "Starting kernel..." >> and seems to be stuck. Removing the video bootargs allows again to boot >> normally. >> >> I must admit that I'm somewhat puzzled by this behavior, as I already >> have daizy running with 3.10.17 on a custom board, and the video is >> working there with almost the same bootargs. Do you guys have any ideas >> for how to configure imx6q sabresd for HDMI video? >> >> Thanks in advance. Regards, >> Nikolay >> -- > Had same here. > > I think there are two problems: > * 3.10.17 EDID decoding works only for monitors with EDID extended > blocks (patch 0001..) > * 1024x768 is not a CEA mode. If I read the code of 3.10.17 correct, > HDMI supports only modes which are found in > drivers/video/mxc/mxc_edid.c const struct fb_videomode > mxc_cea_mode[64]. I hacked up working solution (patch 0002..). Note > that this is just a hack - it might lead to incorrect colour space > conversion or wrong PixelRepetitionOutput (see mxc_hdmi_setup: > hdmi->vic is always 0 for my patches). > > These patches were tested with two monitors (1280x1024 / 1650x forgot>) and seem to work fine. Thanks for your detailed answer. I remember seeing discussions on the net about a safe fallback resolution for imx6 hdmi, so that's the only reason to choose 1024x768. Also, are you sure that the HDMI code doesn't use the CVT (Common VESA Table) resolutions? Need to check this. I'll also look a the code which you pointed me to, and try your patches. I'm not looking for big or pixel-exact resolutions on HDMI, just some reasonable resolution so I can test my gstreamer issues there :). Regards, Nikolay