[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Improve handling of "keep" in gfxpayload

From: Colin Watson
Subject: Re: [PATCH] Improve handling of "keep" in gfxpayload
Date: Mon, 24 Aug 2009 17:38:17 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Aug 24, 2009 at 04:26:09PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Mon, Aug 10, 2009 at 6:41 PM, Colin Watson<address@hidden> wrote:
> > On Mon, Aug 10, 2009 at 06:27:04PM +0200, Vladimir 'phcoder' Serbinenko 
> > wrote:
> >> Framebuffer console works just fine with no KMS if video mode is
> >> already set and video parameters passed. At least technically.
> >
> > Feel free to show me what I'm doing wrong, but it demonstrably does not
> > work right now and right here, and Matthew Garrett (whose opinion I
> > value very highly when it comes to kernelspace) says that the code
> > necessary to make this work does not exist in Linux right now.
> AFAIK efifb does exactly that. Try adding efifb keyword to linux command line.

Right, that's fine once the kernel has woken up to some extent, but it
doesn't load in early boot when it can be important to be able to see
output (drivers only get initialised once the kernel gets up far enough
to call driver_init) and it doesn't address the problem of automatically
unloading the boot console driver later to put a better framebuffer in
place once the kernel has scanned the PCI bus and so on. Besides,
hardcoding the framebuffer module to load in grub.cfg would be bad.

Yes, there are various ways in which this can be hacked up for a given
environment, as long as you don't mind some warts. However, making it
work with no user configuration (as it does right now, aside from the
multiple video mode transitions, if GRUB doesn't do anything special)
really does need actual kernel work. Look at where CONFIG_VGA_CONSOLE is
handled in arch/x86/kernel/setup.c for an example of the sort of thing I

Colin Watson                                       address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]