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

Quoting Geert Uytterhoeven [off-list ref]:

quoted

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

quoted

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