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 ? 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
