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

[Daniel Vetter]

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.

> +/* 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;

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!

> +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.

Cheers, Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch