[RFC] drm: add overlays as first class KMS objects

[Daniel Vetter]

On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Wed, 27 Apr 2011 14:19:05 +0200 Daniel Vetter <daniel at 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
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch