[Intel-gfx] [PATCH 6/6] [drm/i915] implement drmmode overlay support v2

[Daniel Vetter]

On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
> 2009/8/31 Thomas Hellström <thomas at shipmail.org>:
> > Daniel Vetter wrote:
> >
> > ...
> >> In conclusion I don't think a common ioctl is worth it. But sharing some
> >> code and infrastructure on the kernel side is certainly possible, if
> >> someone implements overlay support for another chipset. But I don't really
> >> count on that, because at least radeon has textured video for all it's
> >> chips.
> >>
> > I understand your concerns about the new X architecture where everything
> > is composited, and I admit I haven't looked through your patch in detail.
> >
> > However,
> > we'll _probably_ need to add overlay support to the Xorg gallium + KMS
> > state-tracker shortly, and if so, with that a generic KMS interface that
> > is sufficient to implement a simple Xv overlay adaptor with KMS.

Is this some new (embedded) hw support your working on (that supports
gallium), Thomas? Or why do you think gallium needs overlay support?

> > Given the fact that Xv and various virtual device overlay support
> > implementations exist, I assume there *must* be a way to do this
> > generically. Perhaps not in the interest of sharing kernel code, but in
> > the interest of a single user-space interface and a single user-space
> > implementation supporting multiple hardware drivers.
> 
> I've looked at this before, and you basically end up adding something
> similar to the Xv API in the kernel (for handling pixel formats, size
> & pitch limitations, vsyncing, ...). I'm not sure it's worth it,
> especially since overlays are doomed. Of course overlays are faster
> than textured/blitter video so it's worth implementing, but I'd keep
> this as a device-specific ioctl.
> 
> Stephane

The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this has two solutions:

a) complicated to communicate the constrains to userspace. This is either
to generic or not suitable for everything.
b) one fixed format. If it does not fit, just copy the stuff in the right
format into a new bo. This is what the intel Xv driver does at the moment.
I don't think this belongs into the kernel.

In short I think it's best to do the impedance matching in userspace. We
would need something there anyway to match the various video APIs onto the
kernel model.

Yours, Daniel

btw: I don't think we can sketch out a common interface before we have a second
implementation to go pattern hunting.
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48