2009/8/31 Thomas Hellström <tho...@shipmail.org>: > Daniel Vetter wrote: > > ... >> In conclusion I don't think a common ioctl is worth it. But sharing some >> code and infrastructure on the kernel side is certainly possible, if >> someone implements overlay support for another chipset. But I don't really >> count on that, because at least radeon has textured video for all it's >> chips. >> > I understand your concerns about the new X architecture where everything > is composited, and I admit I haven't looked through your patch in detail. > > However, > we'll _probably_ need to add overlay support to the Xorg gallium + KMS > state-tracker shortly, and if so, with that a generic KMS interface that > is sufficient to implement a simple Xv overlay adaptor with KMS. > > Given the fact that Xv and various virtual device overlay support > implementations exist, I assume there *must* be a way to do this > generically. Perhaps not in the interest of sharing kernel code, but in > the interest of a single user-space interface and a single user-space > implementation supporting multiple hardware drivers. >
I've looked at this before, and you basically end up adding something similar to the Xv API in the kernel (for handling pixel formats, size & pitch limitations, vsyncing, ...). I'm not sure it's worth it, especially since overlays are doomed. Of course overlays are faster than textured/blitter video so it's worth implementing, but I'd keep this as a device-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
