On Mon, May 04, 2009 at 05:59:11PM -0400, BandiPat wrote:
> Robert Millan wrote:
>> Btw, I increased the mode list considerably (using documented modes from
>> Wikipedia). Chances that your ultra-weird mode of choice is supported are
>> much greater now.
>>
>> There's still no fuzzy matching, thou
Robert Millan wrote:
Btw, I increased the mode list considerably (using documented modes from
Wikipedia). Chances that your ultra-weird mode of choice is supported are
much greater now.
There's still no fuzzy matching, though. I'm not sure if we'd want to do
that at all for vga= modes, since w
Btw, I increased the mode list considerably (using documented modes from
Wikipedia). Chances that your ultra-weird mode of choice is supported are
much greater now.
There's still no fuzzy matching, though. I'm not sure if we'd want to do
that at all for vga= modes, since we already do it proper
Am Montag, den 04.05.2009, 14:16 -0400 schrieb BandiPat:
> A little help here. Where do you run this "vbeinfo" command to get a
> listing of suitable modes? I am going to load the vbeinfo.mod in the
> grub.cfg, but what after that to get a listing?
>
Just press `c' to get to commandline and
Robert Millan wrote:
===
Thanks Robert for the suggestion. I had renewed hopes this might work,
but it would not. After editing the menuentry to use either the
vga=0x31b or vga=795, the machine booted to a blinking cursor. It would
not go beyond that.
What suitable modes does "vbe
On Sat, May 02, 2009 at 05:32:01PM +0200, Robert Millan wrote:
>
> See also this new patch. It restructures the checks so that
> "vid_mode == 0" indicates lack of "vga=" parameter. For user requesting
> text mode (vga=normal or vga=0) we already have GRUB_LINUX_VID_MODE_NORMAL
> so there's no ne
On Mon, May 04, 2009 at 11:15:13AM -0400, BandiPat wrote:
> Robert Millan wrote:
>> On Sat, May 02, 2009 at 08:03:23PM -0400, BandiPat wrote:
>>> linux16 /boot/vmlinuz root=/dev/sda1 ro resume=/dev/sda4
>>> splash=silent vga=794
>>
>> This means vga=0x31a, aka 16-bit 1280x1024. Does 24-bit (
Robert Millan wrote:
On Sat, May 02, 2009 at 08:03:23PM -0400, BandiPat wrote:
linux16 /boot/vmlinuz root=/dev/sda1 ro resume=/dev/sda4 splash=silent
vga=794
This means vga=0x31a, aka 16-bit 1280x1024. Does 24-bit (vga=0x31b) work?
I suspect there's some fuzzy matching here.
===
Than
On Sat, May 02, 2009 at 08:03:23PM -0400, BandiPat wrote:
> linux16 /boot/vmlinuz root=/dev/sda1 ro resume=/dev/sda4 splash=silent
> vga=794
This means vga=0x31a, aka 16-bit 1280x1024. Does 24-bit (vga=0x31b) work?
I suspect there's some fuzzy matching here.
--
Robert Millan
The DRM
On Sun, May 03, 2009 at 09:18:02AM -0400, Isaac Dupree wrote:
> Robert Millan wrote:
> > > > > Some
> > > > > kernels may not support VESA modes at all.
> > > >
> > > > I don't think this is applicable; all modern versions of Linux include
> > > > vesa modesetting in its 16-bit entry code, and old
Robert Millan wrote:
> > > > Some
> > > > kernels may not support VESA modes at all.
> > >
> > > I don't think this is applicable; all modern versions of Linux include
> > > vesa modesetting in its 16-bit entry code, and older versions are
> > > already detected by the new loader (user is prompted
Robert Millan wrote:
On Sat, May 02, 2009 at 01:31:14PM +0200, Robert Millan wrote:
"vga=ask" is not a warning now. It causes "error: You need to load the
kernel first", apparently from initrd. In other words, the "linux"
command fails and there is no visible warning.
Sounds like my error cod
On Sat, May 02, 2009 at 01:31:14PM +0200, Robert Millan wrote:
> > > > "vga=ask" is not a warning now. It causes "error: You need to load the
> > > > kernel first", apparently from initrd. In other words, the "linux"
> > > > command fails and there is no visible warning.
> > >
> > > Sounds like
On Tue, Apr 14, 2009 at 02:02:46AM +0200, phcoder wrote:
> With proposed autodetections bootloader becomes overzealous. I think it
> should be configirable but in a more modern way. I think gfxpayload with
> the same syntax as gfxmode plus additional platform-specific keywords
> like text80x2
On Mon, Apr 13, 2009 at 07:20:20PM -0400, Pavel Roskin wrote:
> > We could detect this situation by checking video= parameter, and setting
> > text mode if intelfb is found. But then again do we want to prevent
> > future versions of intelfb from gracefuly transitioning from vesa mode
> > without
Pavel Roskin wrote:
On Mon, 2009-04-13 at 21:05 +0200, Robert Millan wrote:
On Mon, Apr 13, 2009 at 11:41:36AM -0400, Pavel Roskin wrote:
I actually installed GRUB with gfxterm on a laptop that has Intel
framebuffer support. Now the kernel starts in VESA mode and then the
screen goes blank be
On Mon, 2009-04-13 at 21:05 +0200, Robert Millan wrote:
> On Mon, Apr 13, 2009 at 11:41:36AM -0400, Pavel Roskin wrote:
> > I actually installed GRUB with gfxterm on a laptop that has Intel
> > framebuffer support. Now the kernel starts in VESA mode and then the
> > screen goes blank because intel
On Mon, Apr 13, 2009 at 11:41:36AM -0400, Pavel Roskin wrote:
> I actually installed GRUB with gfxterm on a laptop that has Intel
> framebuffer support. Now the kernel starts in VESA mode and then the
> screen goes blank because intelfb cannot deal with it. Sure, intelfb
> should be fixed, but we
On Mon, Apr 13, 2009 at 11:16:46AM -0400, Pavel Roskin wrote:
> On Mon, 2009-04-13 at 16:16 +0200, Robert Millan wrote:
> > Please, in general, when you modify code that has been actively worked on
> > by someone, try to get that person involved.
>
> I tried, but probably not hard enough. Sorry.
On Mon, 2009-04-13 at 16:45 +0200, Robert Millan wrote:
> On Mon, Apr 13, 2009 at 04:16:57PM +0200, Robert Millan wrote:
> > > The default VGA mode is now GRUB_LINUX_VID_MODE_NORMAL, not the mode of
> > > the kernel we tried to load before.
> >
> > Ok, BUT if we're already in vesa mode, and we kno
On Mon, 2009-04-13 at 16:16 +0200, Robert Millan wrote:
> Hi Pavel,
>
> On Mon, Apr 06, 2009 at 11:34:03AM -0400, Pavel Roskin wrote:
> > Hello!
> >
> > This is an attempt to fix all issues with the video mode handling in the
> > new Linux loader.
>
> Please, in general, when you modify code tha
On Mon, Apr 13, 2009 at 04:16:57PM +0200, Robert Millan wrote:
> > The default VGA mode is now GRUB_LINUX_VID_MODE_NORMAL, not the mode of
> > the kernel we tried to load before.
>
> Ok, BUT if we're already in vesa mode, and we know it works (since we're using
> it), there's no point in wasting t
Hi Pavel,
On Mon, Apr 06, 2009 at 11:34:03AM -0400, Pavel Roskin wrote:
> Hello!
>
> This is an attempt to fix all issues with the video mode handling in the
> new Linux loader.
Please, in general, when you modify code that has been actively worked on
by someone, try to get that person involved
On Sun, 2009-04-12 at 21:11 +0200, phcoder wrote:
> Pavel Roskin wrote:
> >> I don't see the code which either handles
> >> GRUB_LINUX_VID_MODE_ASK or passes it to the kernel.
> >
> > We could set params->vid_mode, but the mode setting in the kernel is
> > done in the 16-bit code that we don't u
Pavel Roskin wrote:
I don't see the code which either handles
GRUB_LINUX_VID_MODE_ASK or passes it to the kernel.
We could set params->vid_mode, but the mode setting in the kernel is
done in the 16-bit code that we don't use.
Or we could do the actual asking like linux16 does
Also it looks
On Tue, 2009-04-07 at 09:31 +0200, phcoder wrote:
> Does it actually work?
No. But at least it loads the kernel.
> I don't see the code which either handles
> GRUB_LINUX_VID_MODE_ASK or passes it to the kernel.
We could set params->vid_mode, but the mode setting in the kernel is
done in the 1
Does it actually work? I don't see the code which either handles
GRUB_LINUX_VID_MODE_ASK or passes it to the kernel. Also it looks like
vga= parameter is parsed by grub and grub passes only video mode values
as resolution and color depth. Wouldn't it be better to move to a more
modern video mod
On Tue, 2009-04-07 at 09:31 +0900, Yoshinori K. Okuji wrote:
> > + free_pages();
>
> Please insert a space before the parenthesis.
Done.
> This is not due to you, but the comment above is not synchronized with the
> code apparently. Can you fix it?
Fixed and committed.
--
Regards,
Pavel Ros
On Tuesday 07 April 2009 00:34:03 Pavel Roskin wrote:
> Hello!
>
> This is an attempt to fix all issues with the video mode handling in the
> new Linux loader.
>
> First of all, free_page() doesn't belong to grub_linux_unload(). The
> later function is called after the new kernel has been loaded,
Hello!
This is an attempt to fix all issues with the video mode handling in the
new Linux loader.
First of all, free_page() doesn't belong to grub_linux_unload(). The
later function is called after the new kernel has been loaded, just
before the boot. Thus it obliterates the data set up by the
30 matches
Mail list logo
