Bug#542423: grub-pc: Known upstream bug?

[Felix Zielcke]

Am Sonntag, den 06.09.2009, 20:09 +0200 schrieb Marc Haber:
> Hi,
> 
> On Sun, Sep 06, 2009 at 06:44:19PM +0200, Felix Zielcke wrote:
> > I just wanted to say you can check with the echo line that vga= is
> > handled internaly like `set gfxpayload='
> 
> Ah, I see.

I forgot to mention that this was more for Kai.

> > Check with `insmod vbe;set pager=1;vbeinfo' if the mode you want to use
> > shows up
> 
> vga=791 would mean mode 0x314, which isn't in the list printed by the
> command line. So I'll lose half of my graphics modes that used to be
> useable with grub-legacy?

vbeinfo prints plain VESA numbers, the vga= mode for the Linux was and
is always that + 0x200
so 0x314 means 0x114 in vbeinfo output

vga= works still the same with the old Linux loader linux16/initrd16
which just works like all other bootloaders.

> When I choose a mode which is listed,
> 0x117: 1024x768x16 Direct, mask: 5/6/5/0 pos: 11/5/0/0
> vga=0x117, vga=117 and vga=279 all give a "mode x isn't recognized".
> 
> At least set gfxpayload=1024x768x16 seems to work.

The problem is that the new 32bit Linux loader has to convert the vga=
numbers into height width and bit depth.
So it's more realiable to just use `set gfxpayload' directly.
For example with my Nvidia Geforce vga=0x318 means 1024x768x32 but in
qemu this is 1024x768x24 which also the new Linux loader assumes.
So for me vga=0x318 just doestn't work.

We could use the code from vbeinfo to map the numbers but then it would
make the loader depend on it, which doestn't work for Coreboot and EFI
which share the same loader.

-- 
Felix Zielcke
Proud Debian Maintainer