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

["Leif Lindholm" <leif.lindholm@linaro.org>]

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.
> > 
> > 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.

Regards,

Leif