On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter <daniel@xxxxxxxx> 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.
>
>> +/* 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;
No float in kernel. Would have to use fixed point.
> 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@xxxxxxxx - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
One thing i wonder is if there is hw that doesn't support non tiled
surface at all.
Cheers,
Jerome
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
