Re: [PATCH] Rework vesafb/efifb handling in GRUB

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 07/05/2010 07:00 PM, Colin Watson wrote:
> I've been looking once again at supporting relatively smooth visual
> transitions from GRUB to the kernel, which entails deploying 'set
> gfxpayload=keep' in Ubuntu (I've had it turned off for a while due to
> various reported problems of the black-screen type).  I talked with
> Matthew Garrett (CCed), a Linux kernel developer friend of mine who
> knows about the video subsystem, about what would be involved here.
>
> 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.
>  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.
> so it seems clear to me that GRUB's current code only works by luck.
>
>   

> 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.
> 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"

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature