'Scuse my noobness, but when I supply the following parameter to the arguments
of my kernel through GRUB, I get an 'undefined mode' error:
vga=0164
But then, when the prompt comes up asking me which mode I want I type in:
0164
and I get the required mode!
What's happening? On 2.4 kernel, I used to boot with vga=0x0a (which is the
same mode as 0164) and it would boot fine. Not anymore...
Help?
On Wednesday 22 February 2006 09:43, Asfand Yar Qazi wrote:
> 'Scuse my noobness, but when I supply the following parameter to the arguments
> of my kernel through GRUB, I get an 'undefined mode' error:
>
> vga=0164
>
> But then, when the prompt comes up asking me which mode I want I type in:
>
> 0164
>
> and I get the required mode!
vga parameter is not passed to kernel itself, it is parsed by bootloader.
Previously, booploaders had bugs versus vga=NN specified in hex and/or octal.
Try entering decimal value.
> What's happening? On 2.4 kernel, I used to boot with vga=0x0a (which is the
> same mode as 0164) and it would boot fine. Not anymore...
0x0a != 0164, that's for sure
--
vda
Denis Vlasenko wrote:
> On Wednesday 22 February 2006 09:43, Asfand Yar Qazi wrote:
>
>>'Scuse my noobness, but when I supply the following parameter to the arguments
>> of my kernel through GRUB, I get an 'undefined mode' error:
>>
>>vga=0164
>>
>>But then, when the prompt comes up asking me which mode I want I type in:
>>
>>0164
>>
>>and I get the required mode!
>
>
> vga parameter is not passed to kernel itself, it is parsed by bootloader.
> Previously, booploaders had bugs versus vga=NN specified in hex and/or octal.
> Try entering decimal value.
OK, will try that. decimal of octal(0164) = decimal(116)
>
>
>>What's happening? On 2.4 kernel, I used to boot with vga=0x0a (which is the
>>same mode as 0164) and it would boot fine. Not anymore...
>
>
> 0x0a != 0164, that's for sure
> --
> vda
>
OK, allow me to explain:
When the modes come up on screen, they are numbered (0, 1, 2, ... a, b, etc.)
This is what the 'a' refers to. Hey, it worked through LILO on 2.4 kernels.
Before I type in scan, the number for the 132x60 mode is actually 030C. After
I've typed in 'scan', then it comes up as 0164. If I enter 0164 BEFORE I type
in 'scan' at the vid mode, it still works. But not if I give it as argument
to GRUB. As I said, will try giving decimal equivalent (116) as argument to GRUB.
Hello!
> OK, will try that. decimal of octal(0164) = decimal(116)
This won't work -- the mode numbers are hexadecimal, not octal.
Use 356 (decimal).
> When the modes come up on screen, they are numbered (0, 1, 2, ... a, b,
> etc.) This is what the 'a' refers to. Hey, it worked through LILO on 2.4
> kernels.
Beware, these menu item numbers are _not_ meant to be stable across
kernel upgrades. Better use the "long" mode numbers like 0164 or 030c.
> Before I type in scan, the number for the 132x60 mode is actually 030C.
> After I've typed in 'scan', then it comes up as 0164. If I enter 0164
> BEFORE I type in 'scan' at the vid mode, it still works. But not if I give
> it as argument to GRUB. As I said, will try giving decimal equivalent
> (116) as argument to GRUB.
You can also try giving 0x164 to GRUB.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"Computers are useless. They can only give you answers." -- Pablo Picasso
Martin Mares wrote:
> Hello!
>
>
>>OK, will try that. decimal of octal(0164) = decimal(116)
>
>
> This won't work -- the mode numbers are hexadecimal, not octal.
> Use 356 (decimal).
You're right. I thought '0164' was octal - 0 prefix.
>
>
>>When the modes come up on screen, they are numbered (0, 1, 2, ... a, b,
>>etc.) This is what the 'a' refers to. Hey, it worked through LILO on 2.4
>> kernels.
>
>
> Beware, these menu item numbers are _not_ meant to be stable across
> kernel upgrades. Better use the "long" mode numbers like 0164 or 030c.
Yep, I realise that now :-)
>
>
>>Before I type in scan, the number for the 132x60 mode is actually 030C.
>>After I've typed in 'scan', then it comes up as 0164. If I enter 0164
>>BEFORE I type in 'scan' at the vid mode, it still works. But not if I give
>>it as argument to GRUB. As I said, will try giving decimal equivalent
>>(116) as argument to GRUB.
>
>
> You can also try giving 0x164 to GRUB.
I'll try that as well.
>
> Have a nice fortnight
err... you too :-)
Asfand Yar Qazi wrote:
> Martin Mares wrote:
>
>> Hello!
>>
>>
>>> OK, will try that. decimal of octal(0164) = decimal(116)
>>
>>
>>
>> This won't work -- the mode numbers are hexadecimal, not octal.
>> Use 356 (decimal).
>
>
> You're right. I thought '0164' was octal - 0 prefix.
It worked.
<snip>
>>
>>
>>
>> You can also try giving 0x164 to GRUB.
>
>
> I'll try that as well.
>
It worked as well - obviously I'm using a newer version of GRUB.
Thanks.
>> > OK, will try that. decimal of octal(0164) = decimal(116)
>>
>> This won't work -- the mode numbers are hexadecimal, not octal.
>> Use 356 (decimal).
>
> You're right. I thought '0164' was octal - 0 prefix.
>
Quite misleading. This should be fixed.
Jan Engelhardt
--
Hello!
> > You're right. I thought '0164' was octal - 0 prefix.
> >
> Quite misleading. This should be fixed.
What fix do you propose?
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Air conditioned environment -- Do not open Windows.
>> > You're right. I thought '0164' was octal - 0 prefix.
>> >
>> Quite misleading. This should be fixed.
>
>What fix do you propose?
>
That /^0[xX][0-9a-fA-F]+$/ is required to interpret $_ as a hexadecimal
number, that /^0[0-7]+$/ is required to interpret it as an octal,
and everything else for a normal decimal number.
IOW, using strtol(my_vga_string, NULL, 0) everywhere (GRUB, as well as the
"vga selector" in the kernel).
And making sure the vga selector (i.e. when booting with
vga=ask) always prefix numbers with 0x when they are supposed to be in
hexadecimal, i.e. e.g.
for(i=0; ...)
printf("%#x %dx%d\n", i, vga_modes[i].width, vga_modes[i].height);
instead of currently
printf("%x %dx%d\n", ...)
Jan Engelhardt
--
Hello!
> That /^0[xX][0-9a-fA-F]+$/ is required to interpret $_ as a hexadecimal
> number, that /^0[0-7]+$/ is required to interpret it as an octal,
> and everything else for a normal decimal number.
> IOW, using strtol(my_vga_string, NULL, 0) everywhere (GRUB, as well as the
> "vga selector" in the kernel).
> And making sure the vga selector (i.e. when booting with
> vga=ask) always prefix numbers with 0x when they are supposed to be in
> hexadecimal, i.e. e.g.
> for(i=0; ...)
> printf("%#x %dx%d\n", i, vga_modes[i].width, vga_modes[i].height);
> instead of currently
> printf("%x %dx%d\n", ...)
However, this would change meaning of numbers entered at the video mode
prompt (with vga=ask), which doesn't look good.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Uncle Ed's Rule of Thumb: Never use your thumb for a rule.
>> And making sure the vga selector (i.e. when booting with
>> vga=ask) always prefix numbers with 0x when they are supposed to be in
>> hexadecimal, i.e. e.g.
>> for(i=0; ...)
>> printf("%#x %dx%d\n", i, vga_modes[i].width, vga_modes[i].height);
>> instead of currently
>> printf("%x %dx%d\n", ...)
>
>However, this would change meaning of numbers entered at the video mode
>prompt (with vga=ask), which doesn't look good.
>
Add a warning ;-)
Jan Engelhardt
--
> >However, this would change meaning of numbers entered at the video mode
> >prompt (with vga=ask), which doesn't look good.
> >
> Add a warning ;-)
Well, the same thing can be said about the vga= parameter in LILO and GRUB :-)
I think that the kernel documentation (svga.txt) is pretty clear and explicit
on the meaning of the numbers and I don't see any reasons to change the
behavior of the mode selector.
What IMHO needs updating is the documentation on the vga parameter in LILO
and GRUB docs, which doesn't explain well what's going on.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"A semicolon. Another line ends in the dance of camel." -- Kabir Ahuja