[Top][All Lists]

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

Re: Multiboot video mode request on EFI-gop

From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Multiboot video mode request on EFI-gop
Date: Mon, 16 Jan 2012 16:57:28 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0

On 16.01.2012 16:50, Thomas Nilsen wrote:
Hi again,

Thanks for you help.

That actually means that Grub2 is actually doing what it can and thats it? The rest is up to the os/kernel to handle directly with the GOP protocol driver?

So its not possible to have the GOP driver initialize a mode and then return a LFB address? The GOP protocol in the machine's EFI bios is most definetly not video-hardware specialized, so between the GOP implementation and the VIDEO hardware there must be some sort of LFB type interface? Or am i misunderstanding?

You misunderstand completely. I think you confuse 2 independent structures supplied by GRUB "VBE info" (available only on VBE platforms) and "General video info" (always available includes among other lfb address)
The ideal solution for me would be if grub could initialize mode as it does very well, then in some way get the LFB pointer and bpp, etc and send as if it was from a Bios+vbe grub scenario.


2012/1/16 Phillip Susi <address@hidden <mailto:address@hidden>>

    Hash: SHA1

    On 1/16/2012 10:22 AM, Thomas Nilsen wrote:
    > Hi,
    > I think i might have explained myself incorrect.
    > What i mean is:
    > 1. Grub2 runs very well on BIOS & (U)EFI bios. Nice graphics as
    > requested in gfxmode etc.
    > 2. Grub2 loads multiboot kernel and gives it its requested
    > videomode (from the videomode request part of multibootheader)
    > 3. Grub2 does NOT load multiboot kernel and gives it its requested
    > videomode. It seems to give it its mode, but the info is not right
    > in the multiboot parameters.. So the "kernel" cannot tell what mode
    > it is, where its LFB is and bpp etc.

    Ahh, yes, this is because gop doesn't set a vesa mode and let you play
    with the flat frame buffer.  You actually  make gop calls to perform
    the IO for you.  Grub can leave the display in that state when passing
    off to the kernel, but the kernel has to have its own KMS video driver
    to take over; it can't just start poking at a frame buffer like it can
    with VESA.

    Version: GnuPG v2.0.17 (MingW32)
    Comment: Using GnuPG with Mozilla -

    -----END PGP SIGNATURE-----

Grub-devel mailing list

Vladimir 'φ-coder/phcoder' Serbinenko

reply via email to

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