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 <jbeul...@suse.com>
Acked-by: Roger Pau Monné <roger....@citrix.com> Thanks, Roger.
