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." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
