Keith Whitwell wrote:
I don't think this needs to be that complex. We only need a few working functions in the kernel:
* identification (In particular unique identifier to pass via X to apps
so they can find the head again)
* event reporting (i.e. IRQs and anything else that is relevant)
* mode setting
* memory management
* bitblt
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.
And what about cards with no 2d engine?
A command buffer interface (either mmap()'d buffers or buffers copied using standardized ioctls) with a common command set might be a general approach working on all architectures -- not all card drivers would need to implement all command opcodes, a capability ioctl can return a bitfield of supported opcodes.
Maybe we could use the X11 protocol....
(runs away & hides)
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
