On Mon, Aug 10, 2009 at 02:05:15PM +0200, Vladimir 'phcoder' Serbinenko wrote: > Colin Watson wrote: > > This doesn't quite work perfectly yet. It's better than before - I've > > tested this, and if everything works properly then the result is a > > smooth zero-flicker transition, which is wonderful. However, if > > something goes wrong before the kernel starts a framebuffer then it has > > no way to display any text at all, and it doesn't seem to start one > > until relatively late for me. It may be that the next step here is to > > try to explicitly tell the kernel to set the correct VESA mode rather > > than using 0x0F04, but I thought I'd send this patch anyway in the > > meantime ... > > What is the linux behaviour with 0x0F04? Does it just keep the mode?
Yes, it completely skips modesetting. > What if the same mode is passed as a value? Does linux redoes the > modesetting? Yes, which permits it to display text since now it's set up a linear framebuffer. > If 0x0F04 works ok I would prefer to always pass it when kernel is > booted in graphical mode. VESA mode numbers are an artifact and when > grub2 has its own graphical drivers it won't correspond to anything. It's not the best solution; it's just closer than what's there right now. The problem with 0x0F04 is that the kernel doesn't know how to display text until it brings up its own framebuffer, and we need to figure out how to tell vesafb to come up early so that the kernel can display text if necessary. At the moment it seems that (a) either 0x0F04 or a VESA mode number is appropriate if GRUB is booting in graphical mode; (b) kernel work is needed to do better; (c) as such it is probably not appropriate for GRUB to boot Linux in graphical mode by default just yet. -- Colin Watson [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
