Re: [RFC] support for real graphics hardware

On Friday 29 October 2004 03:43, Ladislav Michl wrote:
> Hi,
>
> I've playing with idea to implement faked framebufer driver fox SGI
> Newport graphics based on REX3 engine (documentation is here:
> ftp://ftp.linux-mips.org/pub/linux/mips/doc/indy/) and fbcon changes
> accepted to 2.6.10-rc1 kicked me to write this post :-)
>
> Now stop reading and see patch below (Note: I didn't test it and even
> tried to compile. It worked with old interface and few tweaks in fbcon,
> but I do not want to spent too much time before some consensus is
> reached)... See drivers/video/console/newport_con.c for putcs
> implementation.
>
> Some video devices act as write-only command pipe. There is no memory
> you can read from, there is even no mapable memory at all.
> However they still can utilize fbdev interface to change resolution and
> for DRM and fbcon to handle fonts settings.
>
> Currently there are two bliting modes: bitblit and tileblit. Extending
> struct fbcon_ops with logo drawing op

This can be done. The logo image can be divided into tiles and fed to
fb_tileblit. But with no users yet, I haven't written any code for it.  (The
potential user is matroxfb though)

> and providing way to register blit
> operations to fb driver itself would allow fb_fillrect, fb_copyarea,
> fb_imageblit and fb_cursor become optional, making wider range of
> hardware happy.

That was one of the goals, in order for matroxfb to support a framebuffer in
text mode, the tileblitting extension was added.

However, it took a lot of pain to separate fbcon from fbdev, and making
struct fbcon_ops visible to the fbdev driver is tantamount to reversing
everything that was done.  So, no, struct fbcon_ops needs to be invisible
from the drivers.

And fb_fillrect|copyarea|imageblit will have to stay, although you are
correct that the above functions are just a subset of tileblitting:-).

> Also having flag for supported font widths would be
> nice, because REX3 cannot handle drawing 1bpp images other that 8*x
> width efectively (zpattern line is misused for that).

We can do this, by adding a field that says that the driver can only do 
blits if source bitmap width is divisible by 8 pixels. I think vga16fb needs
this restriction too.

> These
> modifications would make supporting SGI graphics options easier,
> providing way to change resolution in defined way.
>

Go ahead, write it.  But, do not make struct fbcon_ops visible to the fbdev
driver, use the methods in info->tileops instead and set the
FBINFO_MISC_TILEBLITTING bit in info->flags. The end result should be the same.

Tony




-------------------------------------------------------
This Newsletter Sponsored by: Macrovision 
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate 
today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/