---------- Forwarded message ----------
Date: Fri, 27 Jun 2003 14:17:14 +0600 (GMT-6)
Subject: v2.4.21 vesafb oddity
Thanks for taking the time to read this.
At least for the VESAFB driver in 2.4.21, the framebuffer size is being
miscalculated. This yields wildly different values with different modes.
e.g. (The memory on the card is 2M)
--- fbdmesg-2.4.21 Fri Jun 27 00:01:53 2003
+++ fbdmesg-2.4.21-ac2 Fri Jun 27 00:08:52 2003
. . .
-vesafb: framebuffer at 0xf4000000, mapped to 0xc4800000, size 12288k
+vesafb: framebuffer at 0xf4000000, mapped to 0xc4800000, size 2048k
vesafb: mode is 1024x768x16, linelength=2048, pages=0
vesafb: protected mode interface info at c000:5db2
. . .
In mode 791 (1024x768x16bpp) the stock kernel reports 12288k, while the
-ac kernel correctly reports 2048k. In lower modes (800x600x16bpp etc.)
both kernels report values less than 2048k (1875k, etc.). The patch below
reverts this back to the v2.2 behaviour.
I'm afraid I just don't know the time at which this anomaly began, except
that 2.4.20 (-acN and stock) was fine.
--- linux/drivers/video/vesafb.c.1 Fri Jun 27 00:18:25 2003
+++ linux/drivers/video/vesafb.c Fri Jun 27 00:27:29 2003
@@ -520,7 +520,7 @@ int __init vesafb_init(void)
video_width = screen_info.lfb_width;
video_height = screen_info.lfb_height;
video_linelength = screen_info.lfb_linelength;
- video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp;
+ video_size = screen_info.lfb_size * 65536;
video_visual = (video_bpp == 8) ?
FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;
"Lies, lies, all is lies! Yet beyond I tell you, beauteous and eternal
stands the Truth, Macumazahn."