On Tue, Jul 06, 2010 at 02:16:07AM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 07/05/2010 07:00 PM, Colin Watson wrote: > > Initially I was strongly advocating using efifb for this, since, hey, > > GRUB already uses it by default and labels it as > > GRUB_VIDEO_LINUX_TYPE_SIMPLE, so it must be the simplest option, right? > > Matthew pointed out that GRUB's current behaviour is actually quite > > wrong as far as Linux is concerned. It happens to work with the kernel > > as it is now, because once efifb has been programmed with the > > framebuffer base address etc. it just acts as a simple linear > > framebuffer. However, in the future, the Linux developers might well > > change efifb to support the EFI virtual machine and use EFI for > > modesetting (and they'd be entitled to do so given its name!), > > IMHO it's a plain overkill. efifb main use is to supply the transition > until the real KMS driver is loaded or for recovery situations. > Implementing anything more than framebuffer writing seems to be work for > nothing for me.
Firstly, as far as booting Linux is concerned I think we should be taking the word of the Linux developers when they tell us that setting a particular video ID is inappropriate. It's not our business to define their interfaces for them. Secondly, KMS still doesn't work everywhere and so there'll still be cases where efifb ends up sticking around permanently for one reason or another. > > and at > > this point using efifb on non-EFI systems will break. Matthew said > > "It's really a bug that efifb doesn't check efi_enabled before binding", > > AFAIK EFI doesn't have any useful functions when bootloader is terminated. I'd have to check on this, but I think this is by analogy with the way some BIOS-based drivers call into the video BIOS on resume in order to reinitialise the card. > > All we actually need is a simple linear framebuffer that we can program > > using the boot screen_info structure and that can support displaying > > text quite early in kernel startup (at least to the extent of being able > > to show output if the initramfs fails to mount the root filesystem). > > vesafb gives us this just as well as efifb does. > > No it doesn't. Passing vesafb we claim that: > a) vesa is working > b) mode was set by vesa. > Both assumptions are plainly wrong when GRUB uses native driver, > especially in vbe-free environment. This leads to kernel crash. Interesting. How about we program vesafb when GRUB's vbe driver is active, then? That at least should be perfectly reasonable, and covers the majority of cases on BIOS systems. > > The following patch renames GRUB_VIDEO_LINUX_TYPE_SIMPLE back to > > something less misleading, and programs vesafb rather than efifb on BIOS > > systems. > > I'm ok to use another ID if Linux standartises the ID when bootloader > claims "at this fb address you have a simple framebuffer with following > characteristics, don't even try to use firmware, unload in handover to > real driver for the same card" I think that regardless of this we need to stop using VIDEO_TYPE_EFI, because, frankly, the Linux developers asked us to and it's only polite. I'd like to have something else in place, which is why I'm looking at when we can safely use VIDEO_TYPE_VLFB, but VIDEO_TYPE_EFI isn't documented as a simple linear framebuffer and it's really interface abuse for us to take it over for that purpose without the kernel saying it's OK. Thanks, -- Colin Watson [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
