Re: Multiboot video mode request on EFI-gop

[Vladimir 'φ-coder/phcoder' Serbinenko]

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.
>
> regards
> Thomas
>
> 2012/1/16 Phillip Susi <address@hidden <mailto:address@hidden>>
>
>     -----BEGIN PGP SIGNED MESSAGE-----
>     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.
>
>     -----BEGIN PGP SIGNATURE-----
>     Version: GnuPG v2.0.17 (MingW32)
>     Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>     iQEcBAEBAgAGBQJPFEPEAAoJEJrBOlT6nu75SmgIAJq8XvbE8/g/dtwwVOmwLpgW
>     ahFS5MQU1CCvkmXE54GteIfMVmdLxiRgBdlLH8VxXr4CW19YpYyAWtoi+ib038QB
>     b7DeaReDw2WzYrikw7Ezt1mWejw7t4Ysv1eEjw0ppQlLMm+/Rnwf+qum5nddWeIh
>     ognAT03nqcu+AsOv7G++wiSltNLKXfACrjhdr/VRAmibGT1a5/er0z26evGW1U5/
>     eXWX5kSpsNDuMQILBKvVkLkACK8cC4apKkhATBGA2pGENPgys+fu7NzTJm/j16dt
>     sAuck2a+LpCEJ7os90JwouPVITLeQ05p07LwqJhMMfRkDApoIfgWYXGBFPlTbbE=
>     =EUzD
>     -----END PGP SIGNATURE-----
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel


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