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.warken...@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.lindh...@linaro.org> Pushed as 777573818e0c. Regards, Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#48345): https://edk2.groups.io/g/devel/message/48345 Mute This Topic: https://groups.io/mt/34309623/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
