From: Thomas Backlund <tmb@iki.fi>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: [PATCH 2.4.21-rc6-ac1] vesafb fixes...
Date: Sun, 1 Jun 2003 19:30:02 +0300 [thread overview]
Message-ID: <200306011930.02086.tmb@iki.fi> (raw)
[-- Attachment #1: Type: text/plain, Size: 954 bytes --]
Here are 2 patches...
The "vesafb.txt.diff" removes duplicate text in the documentation...
The "vesafb.c.diff" changes the following:
- it adds "* 2" to the video_size calculation to remap enough memory
to do double buffering
- to make sure that our double buffering calculation does not remap
more memory than old cards actually have it uses the "old" code:
if video_size > (screen_info.lfb_size * 65536)
video_size = screen_info.lfb_size * 65536;
- and last but not least it changes my override to work both ways,
so that the user can specify less or more memory to be remapped
I earlier got a comment that this double buffering thing is not needed,
but IMHO there will always be cards out there that are to new, so they
dont have driver support (yet), or they are too "weird" so the only thing
the user has to rely on is the vesafb driver, and I like the idea to get
atleast this support "out of the box"...
Best Regards
Thomas
[-- Attachment #2: vesafb.c.diff --]
[-- Type: text/x-diff, Size: 1111 bytes --]
diff -Naru ac1/drivers/video/vesafb.c tmb1/drivers/video/vesafb.c
--- ac1/drivers/video/vesafb.c 2003-06-01 18:29:51.000000000 +0300
+++ tmb1/drivers/video/vesafb.c 2003-06-01 18:50:18.000000000 +0300
@@ -525,12 +525,18 @@
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 / 8;
+
+ /* remap memory according to videomode, multiply by 2 to get space for doublebuffering */
+ video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp / 8 * 2;
+
+ /* check that we don't remap more memory than old cards have */
+ if video_size > (screen_info.lfb_size * 65536)
+ video_size = screen_info.lfb_size * 65536;
/* FIXME: Should we clip against declared size for banked devices ? */
/* sets video_size according to vram boot option */
- if (vram && vram * 1024 * 1024 > video_size)
+ if (vram && vram * 1024 * 1024 != video_size)
video_size = vram * 1024 * 1024;
video_visual = (video_bpp == 8) ?
[-- Attachment #3: vesafb.txt.diff --]
[-- Type: text/x-diff, Size: 750 bytes --]
diff -Naru ac1/Documentation/fb/vesafb.txt tmb1/Documentation/fb/vesafb.txt
--- ac1/Documentation/fb/vesafb.txt 2003-06-01 18:29:40.000000000 +0300
+++ tmb1/Documentation/fb/vesafb.txt 2003-06-01 18:33:23.000000000 +0300
@@ -139,12 +139,6 @@
redraw scroll by redrawing the affected part of the screen, this
is the safe (and slow) default.
-vram:n remap 'n' MiB of video RAM. If 0 or not specified, remap memory
- according to video mode. (2.5.66 patch/idea by Antonino Daplas
- reversed to give override possibility (allocate more fb memory
- than the kernel would) to 2.4 by tmb@iki.fi)
-
-
vgapal Use the standard vga registers for palette changes.
This is the default.
pmipal Use the protected mode interface for palette changes.
next reply other threads:[~2003-06-01 16:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-01 16:30 Thomas Backlund [this message]
2003-06-02 13:40 ` [PATCH 2.4.21-rc6-ac1] vesafb fixes Thomas Backlund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200306011930.02086.tmb@iki.fi \
--to=tmb@iki.fi \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox