Everything else is best done as device-specific with the true API belonging in user-space.
Comments ?
Just to say that bitblt covers a lot of ground; ie. there's lots of varieties of blits with quite a few parameters - are you talking about just a simple copy within a single framebuffer, or can source and destination have different pitches? what about different pixel formats? what about fill-blits? etc.
And secondly, that an ioctl per blit probably isn't a useful interface if you're trying to do a lot of small blits, like I guess drawing text. So if you wanted this to be maximally useful, some way of saying 'do these n blits' would make sense.
You are quite right :) I was thinking that we need as much bitblt as one would need to implement a scrolling console: i.e. move areas within framebuffer and use bitmapped fonts. I think that this can be accomplished with an easy API.
For example, what about separating it into two parts:
1) BITBLT ioctl:
/* easy to check against actualy physical boundaries
to prevent lockups, not virtual partition via memory manager */
typedef struct {
long format; /* format key */
long offset; /* location with framebuffer */
long width;
long height;
long pitch;
} SURFACE;typedef struct {
SURFACE dest;
SURFACE source;
} BLIT;typedef struct {
long n_items;
BLIT item[1]; /* expanded as needed to allocate n items */
} BITBLT_ARG;framebuffer->bitblt(FRAMEBUFFER *, (*BITBLT_ARG)); /* in-kernel interface */ ioctl(fd, BITBLT, (BITBLT_ARG *)); /* user-space interface */
2) Memory transfer ioctl: (for exchanging data with framebuffer)
typedef struct {
int direction; /* upload or download */
void *mem_area;
SURFACE framebuffer_surface;
SURFACE memory_surface;
} TRANSFER;typedef struct {
long n_items;
TRANSFER item[1]; /* expand as needed for n items */
} TRANSFER_ARG;framebuffer->transfer(FRAMEBUFFER *,TRANSFER_ARG *); /* in-kernel interface */ ioctl(fd, TRANSFER, (TRANSFER_ARG *)); /* user-space interface */
And what about cards with no 2d engine?
VESA framebuffer (and similar) can use plain memcpy.
3d accelerators without direct access to framebuffer would have some way of transferring memory to the framebuffer and back as well as blits.
Truly weird hardware would require ingenuity - as appropriate.
Comments ?
bestVladimir Dergachev
Keith
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
