Re: [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way)

[David Eger <eger-sender-da68b9@theboonies.us>]

Quoting Geert Uytterhoeven <geert@linux-m68k.org>:

> > 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.

It doesn't so much matter to me.  I just saw some built-in padding in
fb_fix_screeninfo I could steal..

> > 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.

thought this was changed to KD_GRAPHICS and KD_TEXT...

> 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.

If we want the console to display an oops under X then the drawing functions
need to be smart enough to grok the current mode/state of the accel engine and
not rely on var.  Is that what we want?

Comparing pointers just won't work, though.  For example, the radeon driver
decides whether to call the cfb_fillrect() functions or do real hw accel from
within radeonfb_fillrect().

-dte


-------------------------------------------------------
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