From: Keith W. <ke...@tu...> - 2004-05-20 20:59:32
|
Holger Waechtler wrote: > 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 |