Re: [PATCH] Video mode fixes in linux loader

[Robert Millan]

Hi Pavel,

On Mon, Apr 06, 2009 at 11:34:03AM -0400, Pavel Roskin wrote:
> Hello!
> 
> This is an attempt to fix all issues with the video mode handling in the
> new Linux loader.

Please, in general, when you modify code that has been actively worked on
by someone, try to get that person involved.  If I'm to busy to check the
list at a given time, feel free to CC me or msg me on IRC.  Some things
in your patch were not right.

> First of all, free_page() doesn't belong to grub_linux_unload().  The
> later function is called after the new kernel has been loaded, just
> before the boot.  Thus it obliterates the data set up by the last
> "linux" command if the previous Linux boot failed.
> 
> Instead, free_page() should be called from allocate_pages() to reset not
> only real_mode_mem and prot_mode_mem, but also initrd_mem.

Ok.

> Next problem is that grub_linux_boot() can access linux_vesafb_modes
> with a wrong index.  I believe we should threat modes that don't fit the
> array as text modes.
> 
> I introduced GRUB_LINUX_VID_MODE_VESA_START for the first VESA mode we
> support.  Also, I introduced a macro ARRAY_SIZE to calculate the array
> size.

Ok.

> The default VGA mode is now GRUB_LINUX_VID_MODE_NORMAL, not the mode of
> the kernel we tried to load before.

Ok, BUT if we're already in vesa mode, and we know it works (since we're using
it), there's no point in wasting time only to get a worse mode.

We should just make sure subsequent calls to "linux" command override the
previous one.

> Finally, "vga=ask" is now recognized.

With the new loader, Linux' 16-bit entry code is no longer responsible for
setting vesa modes, therefore vga=ask can't work.  There's no point in
recognizing it (except to warn the user).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."