On Thu, 13 May 2004, David Eger wrote:

I fleshed out Geert's idea from the last radeonfb thread on bringing
fbcon's interaction with the underlying framebuffer drivers up-to-date.
Now fbcon should be smart and actually *use* fb-driver provided accel
functions ;-)

Nice!

Specifically, I've added a .hwaccel field to fb_fix_screeninfo, which
should serve as the way framebuffers pass hints to higher layers.

I think we agreed to put it in fb_info instead, since it doesn't really matter
for user space.

This should totally obsolete the accel_flags in var (which till now has
had one half-heartedly used value FB_ACCELF_TEXT).

Well, we still need a way to know when the fbdev has to reinitialize its accel
engine, when switching the console from graphics mode (user space does accel)
to text mode (kernel uses accel). Currently this is done when FB_ACCELF_TEXT is
set.

BTW, we've been talking about allowing kernel messages (mainly oops and panic)
to show up under X. Since we cannot use the accel engine for that, perhaps we
need different routines for fb_{fillrect,copyarea,imageblit}() for the
accelerated vs. non-accelerated cases? And fbcon could compare the function
pointers, instead of looking at .hwaccel.

(Yes, I know it's still possible to lock up your card when using unaccelerated
 drawing while an accelerated operation is in progress on some cards).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click