From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QoAafDsi; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: philmd@redhat.com) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by groups.io with SMTP; Tue, 01 Oct 2019 06:35:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1569936914; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v+FlC3P72tdVi4U9x7hFbi4/ozi0jS53yYz12VNwvdc=; b=QoAafDsicLwz699zYZxAFQEF7r0CUkJh+XFaiVdZaCam2bKIZnOhpKD/b4xJZmp3lvKPo8 9KVy1aI9evwndHKn5UWltYP44Bq9hXaxT1bhinP6mGQ1jyj9HK3lE7c6mEm1Yzt3lyM1BK Axr2K9AeL/PdM/HB0ZDO4XPDocwGEEY= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-175-BXFExY8oMf2s3glfXXL2uA-1; Tue, 01 Oct 2019 09:35:12 -0400 Received: by mail-wr1-f70.google.com with SMTP id v18so5995778wro.16 for ; Tue, 01 Oct 2019 06:35:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jFJpu0Qde0hJ0mLSwzYVa4JExFOcff2FGBvJvumoW8w=; b=Iyrt8p+xUmX2uygIj5/VOBihFPFiswUVALou4Ce03R+DFwfQCUQgsJA7h4BiQakGRp ooJIKevBDUYwXHpQ+1lqfhLsKXpSnREC8NQ18hgSEo4f1q/78IaQyLO5pevr5yI3YfzC uqodkbNw8t0+smCHTGGlOthcMBSlhJ3ULgEb+BW0GbS6P1z4RvoC4MmjoOp5aoB9UuXu cSLNvPz9XH29ZKnNqkoqPfe562LUGYoUUEkHowGi3JhZ+ToU2Ap9gqhFj6c0BXXkB4Cm VDVrKvVZ5IeY9ykoddefu5CoohFKYwgRmT1xx3bIXEGCEfjn/8mo/A8hc6z6MX25JL8e 6HUw== X-Gm-Message-State: APjAAAUKTKocpg/mnSd+2co6fXxWpq2IEVT2PlE9vvZy+3K/Pj9/MiIc aF2KqlpaC93R0Cu9p0t4aG0DS2IAAUy3kAwNc9pJ6MpTV0ibhyGPqmfj1de66ljRHKUbPWm0zvF DPesc6+JwBRQyZg== X-Received: by 2002:a1c:c5cb:: with SMTP id v194mr3741830wmf.108.1569936911472; Tue, 01 Oct 2019 06:35:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqyNntTSCbZKe5MJ5CwU1yEPzq7LvhpusXHFxIiDeBI3//LtcCV5ne7b6H8b0CiSBo2IHh1x3A== X-Received: by 2002:a1c:c5cb:: with SMTP id v194mr3741814wmf.108.1569936911263; Tue, 01 Oct 2019 06:35:11 -0700 (PDT) Return-Path: Received: from [192.168.1.35] (240.red-88-21-68.staticip.rima-tde.net. [88.21.68.240]) by smtp.gmail.com with ESMTPSA id u25sm3100048wml.4.2019.10.01.06.35.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Oct 2019 06:35:10 -0700 (PDT) Subject: Re: [edk2-devel] [edk2-platforms PATCH 1/1] Platforms/RPi3: DisplayDxe virtual resolution improvements To: devel@edk2.groups.io, leif.lindholm@linaro.org, Pete Batard Cc: ard.biesheuvel@linaro.org References: <20190927092016.5604-1-pete@akeo.ie> <20190928230525.GX25504@bivouac.eciton.net> <46241f29-f783-25a2-417b-e42880b5de1d@akeo.ie> <20191001131057.GT25504@bivouac.eciton.net> From: =?UTF-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= Message-ID: Date: Tue, 1 Oct 2019 15:35:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20191001131057.GT25504@bivouac.eciton.net> X-MC-Unique: BXFExY8oMf2s3glfXXL2uA-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10/1/19 3:10 PM, Leif Lindholm wrote: > On Mon, Sep 30, 2019 at 10:32:03AM +0100, Pete Batard wrote: >> Hi Leif, >> >> On 2019.09.29 00:05, Leif Lindholm wrote: >>> On Fri, Sep 27, 2019 at 10:20:15AM +0100, Pete Batard wrote: >>>> From: Andrei Warkentin >>>> >>>> The Pi GPU decouples requested resolution from actual physical resolut= ion >>>> and can perform scaling of virtual resolutions. This enables platform = users >>>> to do something like ask for 1024x768 and get a framebuffer of that si= ze, >>>> regardless of the actual output (which could be a very blurry SDTV). >>>> >>>> Specifically, this patch allows selecting which specific virtual >>>> resolutions to enable, thus replacing the old all-or-nothing behaviour >>>> with either all virtual resolutions supported, or just the native one. >>>> >>>> This patch also adds enables the common 7" Pi (800x480) screen to be u= sed >>>> at 800x600 resolution, instead of forcing 640x480 as the only usable >>>> resolution. Slightly too late nit: " ... also ..." suggest the 7" display forced to=20 800x600 change could have go in a separate patch. >>> >>> I am basically OK with this patch, but I note that the change in >>> variable name/content means existing users will end up with stale >>> variables. >>> >>> So I wonder if it would be worth explicitly adding a stanza deleting >>> the old variable if found? >> >> That would be a valid point *if* the Pi 3 was using actual NVRAM storage= to >> write those variables. >> >> However, we have no such thing on the hardware, so we currently store th= ose >> variables on the SD card, within the firmware file itself. >> >> Which means, the minute you "install" a new firmware (by replacing the >> existing RPI_EFI.fd on your SD card with a new one), you're losing all y= our >> existing variables anyway, including stale ones. >=20 > Ah. That is sort of unique, but I see how it could still be useful. > It was the EFI_VARIABLE_NON_VOLATILE that threw me. >=20 >> Maybe with the Pi 4 and its 512 KB EEPROM, we'll be able to look into >> preserving the variables. Or we may also look into writing variables to = a >> separate virtual NVRAM file on the SD card, instead of just reusing the = .fd >> (which we are doing for convenience). But for our current model, what yo= u >> highlight is a non issue, as the only "upgrade" path forces users to alw= ays >> start with a virtual NVRAM that has been reset and that is therefore fre= e >> from any stale variable. >=20 > Sure. this works. > Reviewed-by: Leif Lindholm > Pushed as 777573818e0c. Thanks Leif. Regards, Phil.