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.
The command buffers might then get verified and executed by the DRM drivers - on the userspace side you would only need to implement a few pretty generic drivers and the fallback code.
The verification code can probably get shared for most or all cards.
Holger
-------------------------------------------------------
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
