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.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.
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.lindh...@linaro.org>
Pushed as 777573818e0c.
Thanks Leif.
Regards,
Phil.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#48347): https://edk2.groups.io/g/devel/message/48347
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]
-=-=-=-=-=-=-=-=-=-=-=-
