Re: [Linux-fbdev-devel] unified accerated interface

[James S. <jsi...@tr...>]

> > They can't be added to 2.2/2.4, because they need the pixel-based
> > functions, 2.2/2.4 accel is cell-based only.
> 
> Do you really have to implement the pixel-based functions for all possible
> values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
> doesn't really need it. That's why we have the support for width field for the
> cell-based operations.

    Well no. I like to think of the accel functions as being more
functionality oriented. When using the accel engine you are not thinking
draw these pixel. You are thinking fill in or copy this area. Their exist
hardware which is not pixel based so I hope the api is flexiable enough to
handle this. 
    The above examples you gave are such a example of not the usually
pixel. mfb easily fits into the cfb. The code I have written supports it. 
I thought about ilbm. Since it is a bunch of bitmaps (1 to N) being one
after another and each bitmap is a collect of a bit value at position X in
the pixel where X is bitmap N. We could easily write soft accel functions. 
For a rectfill it is a matter of taking a color to fill in with and
reading one bit at a time and filling in a are in the bitmap with a group
of 1's or a whole group of 0's. As you can see this could be really fast.
As for drawing a image that has to be units of 8 fbcon handles that by
ensuring only fonts of size of units of 8 are allowed to be used. It
still has the test to prevent something naugthy from happening. As for
userland doing stuff. The drawimage function really not avaliable for
userland. Sure we can have ioctl to test the draw functions for a driver 
but we should leave it at that. Only for debugging purposes.