2009/9/1 Keith Whitwell <kei...@vmware.com>: > On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote: >> Stephane Marchesin wrote: >> > 2009/8/31 Thomas Hellström <tho...@shipmail.org>: >> > >> > >> >>> 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? >> >> >> > >> > Well, for example if your overlay can only do YUY16 in hardware, you >> > still might want to expose YV12/I420 through Xv and do internal >> > conversion. So you'd have to add format conversion somewhere in the >> > stack (probably in user space though). The same happens for swapped >> > components and planar/interlaced; does your hw do YV12, I420, NV12 or >> > something else ? >> > >> > >> The "hw" does YV12, YUY2 and UYVY. >> >> Since the user of this interface (the Xorg state tracker) is generic, >> there's really no point (for us) to >> have driver-specific interfaces that exposes every format that the >> hardware can do. The >> situation might be different, I guess, for device-specific Xorg drivers. >> If we're doing this I think >> we should expose perhaps a reasonable small number of common formats, >> and if the hardware doesn't support any >> of them, the hardware is not going to be supported. >> >> That might unfortunately lead to having driver-specific interfaces for >> the device-specific Xorg driver and a >> generic interface for the Xorg state tracker, and I'm not sure people >> like that idea? > > I'm coming to this late, but if the only difference between hw-specific > and hw-independent interfaces is which formats are supported, that > surely shouldn't be too hard to abstract? Just have an enum which gets > expanded with new format names and query for supported formats in the > API. >
As I said, if my hw overlay only does YUY2 and I want to expose YV12/I420 (because that's what everyone wants), I get to do the conversion myself. Now in the old case I could do it in the driver, but now you can either: - remove it and players stop using the overlay altogether (because few players will convert YV12 to YUY2 themselves) or - do a conversion layer between the formats which gets annoying fast So in the end I will still write a card-specific ioctl. Stephane ------------------------------------------------------------------------------ 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
