Re: [PATCH] Video mode fixes in linux loader

[phcoder <phcoder@gmail.com>]

Pavel Roskin wrote:
>>  I don't see the code which either handles 
>> GRUB_LINUX_VID_MODE_ASK or passes it to the kernel.
> 
> We could set params->vid_mode, but the mode setting in the kernel is
> done in the 16-bit code that we don't use.
Or we could do the actual asking like linux16 does
> 
>>  Also it looks like 
>> vga= parameter is parsed by grub and grub passes only video mode values 
>> as resolution and color depth. Wouldn't it be better to move to a more 
>> modern video mode specification method? As gfxpayload variable 
>> previously discussed on that list
> 
> OK, I just fixed the issue that was annoying me.  Being a PC user, I
> don't really care about the graphical boot.
> 
> After touching that code, I believe the 32-bit Linux loader should not
> parse the vga option at all.  It's irrelevant.
> 
This option may be kept for backward compatibility a possible fallback 
chain is:
gfxpayload->vga->previousvideo mode
> Instead, the loader should either load the kernel in the current mode
> (text of gfxterm) or it should restore the text mode.  I believe not all
> kernels can start in graphical mode, so using the graphical mode should
> be enabled explicitly by some option.
> 
> If the platform doesn't have text mode, then obviously the current mode
> should be used.
> 
> I don't see any strong need to use different video modes in GRUB and in
> the kernel.  If somebody needs that, the mode in GRUB can be changed
> before loading the kernel.  Also, a kernel video driver can change the
> mode upon initialization using driver-specific parameters.
> 
Every OS has its specific needs. E.g. xnu needs to boot in video mode. 
Perhaps it's just me not knowing how to boot it in text mode but this 
limitation will have to be respected. And I don't feel like initialising 
  video console just to set a supported mode is a good idea.
> GRUB could implement video mode handling compatible with the Linux
> internal bootloader, including "vga=ask", but I'm not sure we need it.
> 
I don't think we need it either just no system should be rendered 
unbootable by this

-- 

Regards
Vladimir 'phcoder' Serbinenko