Hi James,
If fbcon will support different methods of rasterizing to the
framebuffer, it's best if display->dispsw is revived. Currently, fbcon
supports classic blitting, but if you decide to add text mode support
(for matroxfb and sbusfb), then tile blitting needs to be supported
too. Also, rotation will require another method, and so will texture
mapping if you ever decide to add this (Isn't this a bit overkill?!).
The struct display is not visible to the drivers, so fbcon need to know
which dispsw to use, possibly based on a new field in struct fb_info or
the presence of the function pointer. I prefer an info->caps field so
drivers need not mangle function pointers.
Here's an updated Tile Blitting patch. The feature is selectable via
kernel configuration (under Advanced Low Level Driver Features).
Currently, it detects the presence of info->tileops but bit setting
info->caps should be better.
The second patch adds generic tile blitting operation, to be used only
for testing purposes since it's very slow. It just wraps fb_imageblit
and fb_copyarea. If anyone wants to test this, just link the driver
cfb_tileops.o, add "info->tileops = &cfb_tileops" during driver
initialization, and enable Tile Blitting support in the kernel.
Tony
PS: reverse the "accel_putcs() optimazation patch" if applied