From: David Eger <eger@havoc.gtf.org>
To: linux-kernel@vger.kernel.org
Subject: Re: radeonfb broken
Date: Tue, 20 Apr 2004 17:09:11 -0400 [thread overview]
Message-ID: <20040420210911.GA9936@havoc.gtf.org> (raw)
On Mon, Apr 19, 2004 at 10:31:27AM -0400, Timothy Miller wrote:
>Ah, so you are the one who wrote the Radeon driver? Thanks for the fix.
Originally it was Ani Joshi's driver. Now BenH maintains it.
I just wrote the acceleration code for radeon for 2.6 ;-)
>One question I have is how to turn on acceleration in the 2.6 kernel.
Funny you should ask. We're discussing over on the fbdev list
( http://linux-fbdev.sourceforge.net/ ) why it's so slow and how to fix it.
It turns out that the fbcon layer has some heuristics to decide how
best to accelerate text rendering (i.e., redraw, call driver accel routines,
or do a screen-to-screen bitblt). These heuristics are just plain *bad*.
At the moment, I just comment out the logic and hard-wire the choice
to "use the driver accel routines, dumbass" as in the excerpt below.
We ought to fix this logic so the video cards indicate which method
is best. The current fields in fb_fix_screeninfo don't really
convey the message well, as you can see in the logic below..
Excerpt from linux/drivers/video/console/fbcon.c:
#define divides(a, b) ((!(a) || (b)%(a)) ? 0 : 1)
/* ... */
static __inline__ void updatescrollmode(struct display *p, struct
vc_data *vc)
{
struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
int m;
/*if (p->scrollmode & __SCROLL_YFIXED)
return;
if (divides(info->fix.ywrapstep, vc->vc_font.height) &&
divides(vc->vc_font.height, info->var.yres_virtual))
m = __SCROLL_YWRAP;
else if (divides(info->fix.ypanstep, vc->vc_font.height) &&
info->var.yres_virtual >= info->var.yres +
vc->vc_font.height)
m = __SCROLL_YPAN;
else if (p->scrollmode & __SCROLL_YNOMOVE)
m = __SCROLL_YREDRAW;
else*/
m = __SCROLL_YMOVE;
p->scrollmode = (p->scrollmode & ~__SCROLL_YMASK) | m;
}
- end Excerpt
So the new driver will work once we patch it to tell fbcon not to be
stupid ;-)
sorry, i'm not sure about setting initial resolution with kernel arguments..
-dte
----- End forwarded message -----
next reply other threads:[~2004-04-20 23:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-20 21:09 David Eger [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-04-15 20:25 Felix von Leitner
2004-04-15 21:13 ` Timothy Miller
2004-04-16 1:43 ` Benjamin Herrenschmidt
2004-04-16 15:58 ` Timothy Miller
2004-04-17 0:22 ` Benjamin Herrenschmidt
2004-04-19 14:18 ` Timothy Miller
2004-04-19 22:36 ` Benjamin Herrenschmidt
2004-04-16 16:06 ` Timothy Miller
2004-04-16 16:40 ` Randy.Dunlap
[not found] ` <20040415152507.3a0b014d.akpm@osdl.org>
2004-04-16 15:56 ` Timothy Miller
2004-04-16 20:34 ` James Simmons
2004-04-16 21:05 ` Timothy Miller
2004-04-19 2:18 ` David Eger
2004-04-16 1:46 ` Benjamin Herrenschmidt
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=20040420210911.GA9936@havoc.gtf.org \
--to=eger@havoc.gtf.org \
--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
all inboxes | Powered by JetHome®