Ping: [PATCH v4 1/8] x86/boot: make "vga=current" work with graphics modes

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.04.2022 16:23, Jan Beulich wrote:
> On 05.04.2022 10:45, Roger Pau Monné wrote:
>> On Thu, Mar 31, 2022 at 11:44:10AM +0200, Jan Beulich wrote:
>>> GrUB2 can be told to leave the screen in the graphics mode it has been
>>> using (or any other one), via "set gfxpayload=keep" (or suitable
>>> variants thereof). In this case we can avoid doing another mode switch
>>> ourselves. This in particular avoids possibly setting the screen to a
>>> less desirable mode: On one of my test systems the set of modes
>>> reported available by the VESA BIOS depends on whether the interposed
>>> KVM switch has that machine set as the active one. If it's not active,
>>> only modes up to 1024x768 get reported, while when active 1280x1024
>>> modes are also included. For things to always work with an explicitly
>>> specified mode (via the "vga=" option), that mode therefore needs be a
>>> 1024x768 one.
>>>
>>> For some reason this only works for me with "multiboot2" (and
>>> "module2"); "multiboot" (and "module") still forces the screen into text
>>> mode, despite my reading of the sources suggesting otherwise.
>>>
>>> For starters I'm limiting this to graphics modes; I do think this ought
>>> to also work for text modes, but
>>> - I can't tell whether GrUB2 can set any text mode other than 80x25
>>>   (I've only found plain "text" to be valid as a "gfxpayload" setting),
>>> - I'm uncertain whether supporting that is worth it, since I'm uncertain
>>>   how many people would be running their systems/screens in text mode,
>>> - I'd like to limit the amount of code added to the realmode trampoline.
>>>
>>> For starters I'm also limiting mode information retrieval to raw BIOS
>>> accesses. This will allow things to work (in principle) also with other
>>> boot environments where a graphics mode can be left in place. The
>>> downside is that this then still is dependent upon switching back to
>>> real mode, so retrieving the needed information from multiboot info is
>>> likely going to be desirable down the road.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> May I ask for an ack or otherwise for the changelog entry, please?

Ping? This is the only thing missing for me to commit the remaining
parts of this series.

Thanks, Jan