2009/9/1 Thomas Hellström <tho...@shipmail.org>: > 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 failing to see why we need an overlay ioctl at all. You end up pulling a relatively large amount of state setup into the drm. Why not treat the overlay like EXA or textured video or 3D? The overlay regs are pipelined on most chips so you can program them from command buffers. Just convert the overlay code in the ddx to use gem/ttm and build an appropriate command buffer or in the case of gallium add overlay support in the device specific code and use gem/ttm, etc.. You could even use it to support GL overlays. Alex > /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 > ------------------------------------------------------------------------------ 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
