Re: [Linux-fbdev-users] Re: [RFC] support for real graphics hardware

[Antonino A. D. <ad...@ho...>]

On Friday 29 October 2004 18:11, Ladislav Michl wrote:
> On Fri, Oct 29, 2004 at 08:05:07AM +0800, Antonino A. Daplas wrote:
> > 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.
>
> Ah, well... Newport can live with that easily, but it's pain for MGras
> (SGI Octane graphics option). You need to setup very complicated DMA to
> support copy area.
>
> > And fb_fillrect|copyarea|imageblit will have to stay, although you are
> > correct that the above functions are just a subset of tileblitting:-).
>
> Now code looks like:
> fbcon_putcs => fbcon_ops->putcs => info->fbops->fb_imageblit
> fbcon_bmove => fbcon_ops->bmove => info->fbops->fb_copyarea
> fbcon_clear => fbcon_ops->clear => info->fbops->fb_filrect

How about:
fbcon_putcs => fbcon_ops->putcs => info->tileops->tileblit
fbcon_bmove => fbcon_ops->bmove => info->tileops->tilemove
fbcon_clear =>fbcon_ops->clear => info->tileops->tilefill

The functions in fbcon_ops and tileops are very, very similar.

>
> So there are four possibilities for MGras:
> 1) Implement console driver (like newport_con.c). That has clear
>    disadvantage of no mode switching API and will cause troubles with
>    adding DRM.
> 2) Implement copyarea in fb driver. That's very compicated (two DMA
>    transfers - 24bit and 1bit) and slower than invalidating area (that
>    is single 1bit DMA transfer) for bmove. (SGI Octane pages are there:
>    http://helios.et.put.poznan.pl/~sskowron/ip30/)

Within fbcon, it is possible to have an unimplemented bmove.  If the driver uses
redraw, or pan_redraw as a scrolling method, fbcon_bmove will never be
called.  However, fbcon_bmove is required by the upper console layer (vt.c)
as a function necessary when inserting or deleting characters.  So it's 
unavoidable to implement bmove, whether using tilemove, or bitmove.

> 3) Hook fb_con operations from driver. You don't like it.

Why not use info->tileops?
 
> 4) Add option to fbcon which will implement bmove by redrawing affected
>    area rather than copying rectangle.

We already have number 4.  See drivers/video/console/fbcon.c:fbcon_redraw_move.

>
> > > 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.
>
> Ok. I remember such flag was there.

It was present in 2.4, removed in 2.6.

Tony