Daniel Vetter wrote: > On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote: > >> 2009/8/31 Thomas Hellström <tho...@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? >
I must stress this is not Gallium. It's the Xorg state-tracker that uses Gallium for acceleration and KMS for modesetting. We want to leverage that to a usable state for an application where we probably can't drop previous (overlay) capabilities. Textured Xv adaptors of course goes through Gallium, Overlay needs to go through KMS. The other possible use I can see is for embedded devices where power is a big concern, but that's nothing we're involved in ATM. I do think, however, that overlays are going to live on for a while in those devices. > >>> 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. > IIRC Xv exposes this all the way down to the user-app, as format and then offset into buffer + stride for each plane? > 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. > Agreed. It's not a problem to implement this in a generic user-space driver. > 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. > OK. We're probably some time away on this. Thanks, /Thomas ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
