Stephane Marchesin skrev: > 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. >
But what stops you from, following Keith's suggestion, exposing _any_ awkward format in a generic ioctl and do format conversion in user-space? The actual struct describing the format will be format-specific, and that way we neither get too restrictive nor too generic? /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
