Re: [PATCH 2.4.21-rc1] vesafb with large memory

Thomas Backlund (tmb@iki.fi)
Thu, 01 May 2003 15:00:29 +0300


O.Sezer wrote:

> So far, so good...
>
> I can happily boot, halt, play some opengl games, perform my daily
> routines, etc. This should also be related to the bug recorded at
> Mandrake-bugzilla: http://qa.mandrakesoft.com/show_bug.cgi?id=3198 .
> I also reported this to kernel@mandrakesoft.com .
>

No need ;-)....
We already have a (IMHO) better patch in current Cooker...
(and if you need it to install MDK 9.1, head over to www.iki.fi/tmb,
grab the install disks, and follow the instructions...)

The problem with the patch you discussed, is that it allocates
framebuffer memory only according to the display mode...,
but there are programs that benefits from the "extra" memory...
this according to Antonino Daplas...
(AFAIK double/triple buffering is one thing...)

The patch that we have in current Cooker, allows the user to
request the size himself by a command line option...
and it does not change the setup/configuration for users that
does not suffer from this problem...

the patch works like this:

you request the framebuffer size with "video=vesa:vram:32"
where 32 is the requested size in MB...
(you can choose the size yourself)
but a gemeric rule IMHO is to not go beyond the amount
of video memory you have...

and when the system boots:

- if no vram option, boot as normal (like without the patch)
- if probed memory > requested, use requested
- if probed memory < requested, use probed (like without the patch)

As a test I used this "video=vesa:vram:32" on a card
with 64MB of ram, and on a card with only 4MB of ram
to se if I could mess it up, with the following results:

64MB card: allocated FB -> 32MB
(this is also confirmed on a 128MB card, by other Cooker users)
4MB card: allocated FB -> 4MB
(here the original probe worked, so we use it...)

So this way we wont break current systems,
but have an option for those cards that has problem...
(seems to be AGP + >=128MB VideoRAM + >=1024MB system RAM only)

and finally... the patch itself:

----- cut -----
diff -Naru tmb7/Documentation/fb/vesafb.txt tmb9/Documentation/fb/vesafb.txt
--- tmb7/Documentation/fb/vesafb.txt 2000-07-28 22:50:51.000000000 +0300
+++ tmb9/Documentation/fb/vesafb.txt 2003-04-03 10:48:50.000000000 +0300
@@ -146,6 +146,10 @@

mtrr setup memory type range registers for the vesafb framebuffer.

+vram:n remap 'n' MiB of video RAM. If 0 or not specified, remap all
+ available video RAM. (2.5.66 patch by Antonino Daplas backported
+ to 2.4 by tmb@iki.fi)
+

Have fun!

diff -Naru tmb7/drivers/video/vesafb.c tmb9/drivers/video/vesafb.c
--- tmb7/drivers/video/vesafb.c 2002-11-29 01:53:15.000000000 +0200
+++ tmb9/drivers/video/vesafb.c 2003-04-03 10:46:52.000000000 +0300
@@ -94,6 +94,7 @@

static int inverse = 0;
static int mtrr = 0;
+static int vram __initdata = 0; /* needed for vram boot option */
static int currcon = 0;

static int pmi_setpal = 0; /* pmi for palette changes ??? */
@@ -479,6 +480,10 @@
pmi_setpal=1;
else if (! strcmp(this_opt, "mtrr"))
mtrr=1;
+ /* checks for vram boot option */
+ else if (! strncmp(this_opt, "vram:", 5))
+ vram = simple_strtoul(this_opt+5, NULL, 0);
+
else if (!strncmp(this_opt, "font:", 5))
strcpy(fb_info.fontname, this_opt+5);
}
@@ -521,6 +526,9 @@
video_height = screen_info.lfb_height;
video_linelength = screen_info.lfb_linelength;
video_size = screen_info.lfb_size * 65536;
+ /* sets video_size according to boot option */
+ if (vram && vram * 1024 * 1024 < video_size)
+ video_size = vram * 1024 * 1024;
video_visual = (video_bpp == 8) ?
FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
----- cut -----

Best Regards

Thomas Backlund

tmb@iki.fi
www.iki.fi/tmb

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/