Re: [edk2-devel] [edk2-platforms PATCH 1/1] Platforms/RPi3: DisplayDxe virtual resolution improvements

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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 <andrey.warkentin@gmail.com>
>>>>
>>>> The Pi GPU decouples requested resolution from actual physical resolution
>>>> and can perform scaling of virtual resolutions. This enables platform users
>>>> to do something like ask for 1024x768 and get a framebuffer of that size,
>>>> 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 used
>>>> at 800x600 resolution, instead of forcing 640x480 as the only usable
>>>> resolution.

Slightly too late nit: " ... also ..." suggest the 7" display forced to 
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 those
>> 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 your
>> existing variables anyway, including stale ones.
> 
> 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.
> 
>> 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 you
>> highlight is a non issue, as the only "upgrade" path forces users to always
>> start with a virtual NVRAM that has been reset and that is therefore free
>> from any stale variable.
> 
> Sure. this works.
> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
> Pushed as 777573818e0c.

Thanks Leif.

Regards,

Phil.