Hi, Brian,

The patch is OK for me.

Please cc linux-fbdev-devel@lists.sourceforge.net and "Antonino A.
Daplas" <adaplas@pol.net> on framebuffer driver patches.

Best Regards,
Huang Ying

On Sun, 2009-03-22 at 06:16 +0800, Brian Maly wrote:
> The current logic for dmi matching in efifb does not allow efifb to load 
> on all hardware that we can dmi match for.
> 
> For a real world example, boot with elilo (3.7 or 3.8 vanilla) and on a 
> Apple (MacBook) and EFI framebuffer driver will not load (you will have 
> no video).
> This specific hardware is efi v1.10, so we have UGA and not GOP. Without 
> special bootloader magic (i.e. extra elilo patches for UGA graphics 
> detection) no screen info will be passed to the kernel and as a result 
> efifb will not load.
> 
> This patch allows the dmi match to happen by moving it to earlier in 
> efifb_init, and sets the video type (in set_system) so that efifb can 
> load when we have a valid dmi match and already know the specifics of 
> the hardware.
> 
> Without this patch the efifb driver will fail to load in the event 
> screen info is not found and passed in by the bootloader, being that we 
> will never get to look for a dmi match. A primary reason for matching 
> with dmi is because not all bootloaders detect the video info properly. 
> The solution is that in the event of a dmi match, we should set 
> screen_info.orig_video_isVGA. Most bootloaders fail to set screen info 
> on Apple hardware, and this is a big problem for people who use Apple 
> hardware.
> 
> Tested on a MacBook SantaRosa with elilo-3.8 (vanilla) and resolves the 
> issue, the dmi match now works, EFI framebuffer now loads and video works.
> 
> 
> Signed-off-by: Brian Maly <bmaly@redhat>
> 
>