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? /Thomas > That said, if someone achieves a generic ioctl that can do this, I > have nothing against it. It's just that it seems to be a lot of work > for little benefit (IMO). > > 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
