From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id DEAC1E008C3; Thu, 13 Nov 2014 09:50:58 -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 2DF67E00831 for ; Thu, 13 Nov 2014 09:50:54 -0800 (PST) Received: from [192.168.0.40] (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 256486000728; Thu, 13 Nov 2014 19:50:53 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1415901053; bh=hWIDPxFc1Iwqi2pJHmV1Rkc2Zhzki7pjmNJqtcVdkzc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZvK9fBtewE/XGr40xojyuDpGIE+8DkefhSobc+YrdNshCetNGW/d9WtbzcD2ZsMhf iaBMSf5BZv81n6e1xUJkrd7bNsJfgQ8UFGq3P9X3ErCzj9N/oWCyBjn5hMPTGfIle4 M7FZkHaqpwqva7UTbOsGSVzeHybF0pOVhO8qu9pM= Message-ID: <5464EF77.3030600@mail.bg> Date: Thu, 13 Nov 2014 19:50:47 +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> <5464CB9A.8040000@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 17:50:58 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andreas, On 11/13/2014 05:48 PM, Andreas Müller wrote: > On Thu, Nov 13, 2014 at 4:17 PM, Nikolay Dimitrov wrote: >> 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 > After re reading this thread I saw that my patches are addressing a > different problem. In short: Whatever monitor I connected to HDMI (via > DVI) I got only 640x480 and complaints like > > [ 0.829299] mxc_hdmi 20e0000.hdmi_video: mxc_edid_read_internal > [ 0.960509] mxc_hdmi 20e0000.hdmi_video: Read EDID again > [ 0.960522] mxc_hdmi 20e0000.hdmi_video: mxc_edid_read_internal > [ 1.091703] mxc_hdmi 20e0000.hdmi_video: No modes read from edid > [ 1.091714] mxc_hdmi 20e0000.hdmi_video: create default modelist Ahh, I see. Yes, I also think they are 2 separate issues. Still, thanks for trying to help. Regards, Nikolay