Ahh,, I found it!
This thing passed me by. In the multiboot_info header i was using
vbe_modeinfo and got lfb from there..
I can see that a few bytes further into the array there is also a part
"
multiboot_uint64_t framebuffer_addr;
multiboot_uint32_t framebuffer_pitch;
multiboot_uint32_t f
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 a
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
On 16.01.2012 16:22, 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
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
Hi,
Im currently doing some research into some low level systems loaded by
grub2 trough (E)EFI and legacy bios.
Grub2 seems to honor the "requested video mode" setting in multiboot header
very well on BIOS.
When booting trough EFI, then of course VBE is not possible, and it also
seems that for e
