> > well, the mmap is actually implemented by the buffer allocator > (v4l/drm).. although not sure if this was the point Then why not use the correct interface? doing some sort of not-quite generic interface isn't really helping anyone except adding an ABI that we have to support. If someone wants to bypass the current kernel APIs we should add a new API for them not shove it into this generic buffer sharing layer. > The intent was that this is for well defined formats.. ie. it would > need to be a format that both v4l and drm understood in the first > place for sharing to make sense at all.. How will you know the stride to take a simple example? The userspace had to create this buffer somehow and wants to share it with "something", you sound like you really needs another API that is a simple accessor API that can handle mmaps. > Anyways, the basic reason is to handle random edge cases where you > need sw access to the buffer. For example, you are decoding video and > pull out a frame to generate a thumbnail w/ a sw jpeg encoder.. Again, doesn't sound like it should be part of this API, and also sounds like the sw jpeg encoder will need more info about the buffer anyways like stride and format. > With this current scheme, synchronization could be handled in > dmabufops->mmap() and vm_ops->close().. it is perhaps a bit heavy to > require mmap/munmap for each sw access, but I suppose this isn't > really for the high-performance use case. It is just so that some > random bit of sw that gets passed a dmabuf handle without knowing who > allocated it can have sw access if really needed. So I think thats fine, write a sw accessor providers, don't go overloading the buffer sharing code. This API will limit what people can use this buffer sharing for with pure hw accessors, you might say, oh buts its okay to fail the mmap then, but the chances of sw handling that I'm not so sure off. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
