From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=212.227.17.22; helo=mout.gmx.net; envelope-from=nico.h@gmx.de; receiver=edk2-devel@lists.01.org Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id ADF2821E256BE for ; Sun, 28 Jan 2018 06:28:30 -0800 (PST) Received: from [192.168.4.129] ([130.180.109.134]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LtUHA-1enKV62iU0-010swB; Sun, 28 Jan 2018 15:33:56 +0100 To: "You, Benjamin" , "edk2-devel@lists.01.org" Cc: Arthur Heymans References: <20180124105736.14877-1-arthur@aheymans.xyz> <87mv12gvjc.fsf@aheymans.xyz> <87efmdyokj.fsf@aheymans.xyz> From: Nico Huber Message-ID: Date: Sun, 28 Jan 2018 15:33:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: X-Provags-ID: V03:K0:JeVOIxHosBkyOQ/sRkwye7mabOGaigUhV1uOjFlfg7urNyhRrwl jdJ1MaTEr3VS2rNGrc+rKNgd9y9DOPskw+G2OcBRbBRZGwSTdZotxCJ19IiVLuiHjksUOoS uGqsB61WAxTW4Tz8mjVpg+gkDKdInkrQReSr7I4kSACSKA9x1TinmiahkhJZpsDatTW9/H9 vfIIs4HqzKEWfw73r6mnQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Eff//ov96Ik=:kISCKmc4rnEk2JKubmvpvw HQPLcWBBA9mGaKib2lpiPkJgXmg5rPyIou20tVdYCFL13CXRaXzRf/diq+pqF1tGX/lHGOnx9 B6J9i+TMtYaB7J61nAJuEXUsBLL5tug9Wkf8Wy/3HD5b/5T4b4oJNFjSfyk9MmRACvo29zZy2 CvVAtF98l+C8UiHIJlet82t+MDv5MZkwc0ZOsN0t0yp0pf3U4Q8NDE8SxBUv7W3+73y/70spz 4W6UU17hsr/eGzk3jbevOuZK3NcT15oPF3kstlJ6BmK5k4Xm37JWK3XuaAT7AIvq15LIxZEoh d1mgQ0Rii/VYn/vLoezwNBmobdwmonn4Ujr7brDWQcdubMNtd/dDL98qUrOi2b4R6yRiCJpTN 2F14/lJ5UwP18SVYqvqwZJFM/3ttehGyVclKJWTh0B0O0xCKbkwp3vKUQ1R7Ld8Op9AA7obNi Wf11Q74HYBG5fC0toqbz2hSN6QZvGpoqSLu/djnOJKgTTz7QP3NTfQmo5NfSPnYnmIhKCQu8b NiVDVPVraw/CCfVwo4MZAaxa/IE8cM5B+w4xfxeZ1XW6lWQlmT6YfMX4CjzYUVnWgpSll/OMW 8qQnsCPtQxcvnPT08V7KDTusz2xt5p+RxIpEcISCxVNTh141d89B7UqmU4koRps/2VDb6yehY LlSPs08KuvZSQpR82Oql7MpurDiWXFSAePUj4nF0XPu08BbvnL8QM2wApYIxhJMxolAf02NDg uF4uE531DVQ2RD2/ztDkP2A5bg/KRHsiwgbN8NBlv0Hz7vjZCiTvdNFmFEghtdK3hces2gGbs AKg01TzG51lrRbpW6Na4jrmtqc6Adl+oe2pkaxIb4DZUUGhomk= Subject: Re: [PATCH] CorebootPayloadPkg: Use correct BytesPerScanLine X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 14:28:31 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Ben, On 28.01.2018 09:49, You, Benjamin wrote: > Hi Nico, > > Thanks for the detailed information. It makes sense. I do like the idea of > documenting the lb_framebuffer. > >> The only guarantee for `bytes_per_pixel` (typo? 'bytes_per_scanline') yes, typo. >> and `x_resolution` you get as a consumer, is that the former is big >> enough to hold `x_resolution` pixels. > > I think it would be good to also document that the consumer is assured that > in framebuffer, all the 'x_resolution' pixels are aligned at the beginning > of each scanline, and the extra bytes are always padded after the > 'x_resolution' pixels in the scanline. Would this be true with existing > graphics devices? (I am not expert in this area so I'd like to confirm.) Yes, that's true. I've started to document the whole thing now: https://review.coreboot.org/#/c/coreboot/+/23466/4/src/commonlib/include/commonlib/coreboot_tables.h@214 The same applies in principle to EFI_GRAPHICS_OUTPUT_MODE_INFORMATION. This framebuffer layout is very common. Nico