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

[Jesse Barnes]

On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter <daniel at ffwll.ch> wrote:

> Hi Jesse,
> 
> I like it. It's a bit of a chicken-egg api design problem, but if a
> proof-of-concept
> implementation exists for an embedded chip plus something to check whether
> it's good enough to implement Xv on ancient hw (intel overlay or for the qemu
> kms driver, if that could do this), that should be good enough.
> 
> A few comments on the ioctl interface.

Thanks for checking it out.

> > +/* Overlays blend with or override other bits on the CRTC */
> > +struct drm_mode_set_overlay {
> > +       __u32 overlay_id;
> > +       __u32 crtc_id;
> > +       __u32 fb_id; /* contains surface format type */
> > +
> > +       __u32 crtc_x, crtc_y;
> > +       __u32 x, y;
> > +
> > +       /* FIXME: color key/mask, scaling, z-order, other? */
> > +};
> 
> I think scaling is required, you can't implement Xv without that. The
> problem is some arbitraray
> hw range restrictions, but returning -EINVAL if they're violated looks okay. So
> 
> float scale_x, scale_y;

Ok, I'll collect more fields based on this thread and make this
structure bigger.  Still not sure how to handle arbitrary blend and
z-order restrictions without passing a tree around though...

> 
> should be good enough. For the remaining things (color conversion,
> blending, ...) I don't think
> there's any generic way to map hw capabilities (without going insane).
> I think a bunch of
> properties (with standard stuff for gamma, color key, ...) would be
> perfect for that. If we
> set the defaults such that it Just Works for Xv (after setting the
> color key, if present), that
> would be great!

Yeah, properties for those is probably the way to go.

> 
> > +struct drm_mode_get_overlay {
> > +       __u64 format_type_ptr;
> > +       __u32 overlay_id;
> > +
> > +       __u32 crtc_id;
> > +       __u32 fb_id;
> > +
> > +       __u32 crtc_x, crtc_y;
> > +       __u32 x, y;
> > +
> > +       __u32 possible_crtcs;
> > +       __u32 gamma_size;
> > +
> > +       __u32 count_format_types;
> > +};
> 
> 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.

Jesse