On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes jbarnes@virtuousgeek.org wrote:
On Wed, 27 Apr 2011 14:19:05 +0200 Daniel Vetter daniel@ffwll.ch wrote:
Imo the real problem with formats is stride restrictions and other hw restrictions (tiling, ...). ARM/v4l people seem to want that to be in the kernel so that they can e.g. dma decoded video streams directly to the gpu (also for other stuff). Perhaps we want to extend the create_dumb_gem_object ioctl for that use case, but I'm not too convinced that this belongs into the kernel.
I think it's a bit like handling tiling formats; for the most part the kernel doesn't care because it's not reading or writing the data, but it does need to know the format when programming certain regs. So I don't think we can avoid having surface format information passed in when creating an fb for an overlay. And if we do that we may as well enumerate the types we support when overlay info is fetched to make portability for app code a little easier.
I agree with your design ;-) My above comment was just in the light of the ARM unified memory management discussion where some people seem to want to move a complete buffer format description beast into the kernel (like v4l already has). I think for gpus that'd get out of hand quickly and format/layout arbitrage code should life in userspace. -Daniel