[Solved] VBoxInternal2/EfiGopMode not honored

[socratis]

---

[Solved]
There are two new variables that have to be set:

• "VBoxInternal2/EfiHorizontalResolution" and
• "VBoxInternal2/EfiVerticalResolution".

So, instead of EfiGopMode=3, you should use:

VBoxManage setextradata "<VM>" VBoxInternal2/EfiHorizontalResolution 1280
VBoxManage setextradata "<VM>" VBoxInternal2/EfiVerticalResolution 1024

---

• Host: OSX 10.11.6 (15G1611).
• Guest: Any OSX with EfiGopMode set.
• VirtualBox: Version 5.2.0_BETA1 r117406 (Qt5.6.2).

The title pretty much says it all. My OSX guests all have:

Code: Select all

      <ExtraDataItem name="VBoxInternal2/EfiGopMode" value="3"/>

for a resolution of 1280x1024. This is not honored in r117406. I know that there have been a lot of changes in the EFI graphics area to accommodate more and merrier resolutions:

1. Shouldn't older settings be honored?
2. What's the appropriate setting to restore custom resolutions?

[pentagonik]

Thanks for letting us know. We're investigating that ASAP.

[socratis]

Not sure if it's related to r67918, but that changeset also contains changes to the VBox.log, which propagated apparently OK:

00:00:01.223877 [/Devices/efi/0/Config/] (level 4)
00:00:01.223879   64BitEntry           <integer> = 0x0000000000000001 (1)
00:00:01.223879   APIC                 <integer> = 0x0000000000000001 (1)
00:00:01.223880   BootArgs             <string>  = "" (cb=1)
00:00:01.223881   DeviceProps          <string>  = "" (cb=1)
00:00:01.223881   DmiExposeMemoryTable <integer> = 0x0000000000000001 (1)
00:00:01.223883   DmiUseHostInfo       <integer> = 0x0000000000000001 (1)
00:00:01.223883   EfiRom               <string>  = "/Applications/VirtualBox.app/Contents/MacOS/VBoxEFI64.fd" (cb=57)
00:00:01.223884   GraphicsMode         <integer> = 0x0000000000000003 (3)    <-- Picked up correctly
00:00:01.223885   HorizontalResolution <integer> = 0x0000000000000000 (0)
00:00:01.223885   IOAPIC               <integer> = 0x0000000000000001 (1)
00:00:01.223886   McfgBase             <integer> = 0x00000000dc000000 (3 690 987 520)
00:00:01.223887   McfgLength           <integer> = 0x0000000004000000 (67 108 864)
00:00:01.223888   NumCPUs              <integer> = 0x0000000000000002 (2)
00:00:01.223889   UUID                 <bytes>   = "7e 16 b9 a5 25 dc b7 46 ad a2 6c 4b d3 98 a7 d1" (cb=16)
00:00:01.223891   VerticalResolution   <integer> = 0x0000000000000000 (0)

[klaus]

Sorry that the EFI changes (which are only 80% complete in BETA1) are at the moment totally undocumented. The EfiGopMode extradata is now purely a fallback, which is practically never used. Mode matching is now primarily done by resolution (not by number, as the numbers are relatively volatile, since they depend to some extent on the available VRAM size, as I intend to keep the list of modes sorted by horizontal, then by vertical resolution, keeping only the modes which fit into VRAM). The list of modes is now much, much longer (e.g. the long awaited Full HD resolution of 1920x1080 is now available - overall about 30 common monitor resolutions up to 8K). There's a plan to add custom resolutions, too. Yes, we heard the pledges, but the code isn't written yet.

This means that you now need to use a style similar to the UGA config method (actually the UGA stuff does work, too, but since UGA is totally obsolete these days it's not necessary to confuse people with it). Set the resolution with the following extradata keys:
VBoxInternal2/EfiHorizontalResolution
VBoxInternal2/EfiVerticalResolution

Now that I'm thinking about this topic again I don't like the need to set two extradata values for picking the resolution... probably will change before 5.2 is finalized. So don't use this post as a true replacement for the docs, just as a stopgap solution.

[socratis]

The EfiGopMode extradata is now purely a fallback, which is practically never used.

Hmm... That's why I quoted r67918, because I did see the fallback code to the "GraphicsMode". But... in the same changeset, there is no "EfiHorizontalResolution" nor "EfiVerticalResolution", only "HorizontalResolution" and "VerticalResolution". And I tried all three of the new parameters. To a spectacular failure, as you can imagine

And on top of that, there is no mention of these two parameters in the public trunk (which was updated today to r68300, after the beta release), or the source code for 5.2.0b1, which is not out (yet?). What's going on?

Set the resolution with the following extradata keys:
VBoxInternal2/EfiHorizontalResolution
VBoxInternal2/EfiVerticalResolution

These two ones that you posted work like a charm! We're back to business!!! I'll keep both of the EfiGopMode and the Efi*Resolution, because I frequently switch between different VirtualBox versions. I hope they all get honored, even if the first one is deprecated in 5.2.x.

I intend to keep the list of modes sorted by horizontal, then by vertical resolution, keeping only the modes which fit into VRAM). The list of modes is now much, much longer (e.g. the long awaited Full HD resolution of 1920x1080 is now available - overall about 30 common monitor resolutions up to 8K).

Do you mean the "VBoxVgaVideoModes[]" in "vbox/src/VBox/Devices/EFI/Firmware/VBoxPkg/VBoxVgaDxe/VBoxVga.c"? I'll definitely try the 8K one (7680x4320), just for kicks. I expect long, long scroll bars!

[socratis]

I'll definitely try the 8K one (7680x4320), just for kicks. I expect long, long scroll bars!

Well... That was fun. Not!

But then it started being really funny when I pumped the resolution to 8K and the scale factor to 0.2. You really had to search for the mouse...

Bottom line, it works as advertised. Really cool. Great job Klaus!!!

[klaus]

The EfiGopMode extradata is now purely a fallback, which is practically never used.

Hmm... That's why I quoted r67918, because I did see the fallback code to the "GraphicsMode". But... in the same changeset, there is no "EfiHorizontalResolution" nor "EfiVerticalResolution", only "HorizontalResolution" and "VerticalResolution". And I tried all three of the new parameters. To a spectacular failure, as you can imagine

And on top of that, there is no mention of these two parameters in the public trunk (which was updated today to r68300, after the beta release), or the source code for 5.2.0b1, which is not out (yet?). What's going on?

You're looking at the change one level too low. This is configured through 'API tweak extradata', i.e. VBoxInternal2, not the usual VBoxInternal extradata stuff which ends up directly in the CFGM settings which the devices pick up. So it's a bit more indirect than what you have in mind, adding more default handling on the way (besides the relatively well hidden behavior change in EFI itself). A good portion of the change is in r67918, but it doesn't show the fallback order too clearly as most of the code is just passing on values (possibly with some defaults if not set).

Set the resolution with the following extradata keys:
VBoxInternal2/EfiHorizontalResolution
VBoxInternal2/EfiVerticalResolution

These two ones that you posted work like a charm! We're back to business!!! I'll keep both of the EfiGopMode and the Efi*Resolution, because I frequently switch between different VirtualBox versions. I hope they all get honored, even if the first one is deprecated in 5.2.x.

I intend to keep the list of modes sorted by horizontal, then by vertical resolution, keeping only the modes which fit into VRAM). The list of modes is now much, much longer (e.g. the long awaited Full HD resolution of 1920x1080 is now available - overall about 30 common monitor resolutions up to 8K).

Do you mean the "VBoxVgaVideoModes[]" in "vbox/src/VBox/Devices/EFI/Firmware/VBoxPkg/VBoxVgaDxe/VBoxVga.c"? I'll definitely try the 8K one (7680x4320), just for kicks. I expect long, long scroll bars!

Yes, that's the new list of known modes. If a popular monitor resolution is missing the resolution based mode matching allows adding without everyone out there adjusting his settings. Yes, it'll cause a bit of pain initially for people who used EFI for a while, but I don't like having a mode list which is getting more and more random over time. EFI can't have gaps in the mode list, so once adding custom modes for EFI is implemented the last bit of the meaning of the mode numbers would be gone.