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....
Well, X11 protocol was designed rather well.
kind of overkill for this purpose, not? A command set that allows using the opcodes easily to jump directly into the verification function table and if the request is allowed into the function table that contains the i/o programming routines might get coded pretty compactly.
We can simplify the matters quite a bit by requiring that writes to the fd always send N whole packets (and don't break on per-packet boundaries).
On the other hand we would probably want to modify the protocol at least in the following way:
1) take into account modern hardware.. no short width anymore, more pixel formats.
The pixel format is a source or destination surface format flag, there should be no need to encode it in rendering commands, only in surface creation/allocation commands.
2) only require parts essential for console implementation - everything
else could be passed back to user-space daemon. (Note that if
user-space daemon is not present this would mean that things like
line-drawing packets would fail..)
yes.
1) implies that we are not going to be binary compatible with usual X11 protocol, so we are implementing a new protocol nevertheless which means this whole point rather academic: if one designs a new protocol there is no reason not to take into account design of X11.
(a full fledged X11 implementation in the kernel might have some problems to get accepted by the lkml codingstyle policemen;)
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
