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 <[email protected] <mailto:[email protected]>>
-----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
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel
