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