You are sort-of correct. Mark and I actually had some discussions about making a more expanded version of it or another API that was more generic.
In the implementation for i810 You can allocate XvMC surfaces and then, if you know where to look. You can access the surfaces directly as they are mapped into your memory space via DRM. You can then just use the XvMCPutSurface() to get the surface displayed on the overlay, complete with Top surface/Bottom Surface functionality and very small latency. The problem is that while I implemented XvMC by mapping the surfaces into the clients memory, there is no requirement to do so, and no generic way to access the surfaces. Plus there is no good way for DRM to dynamically handle adding and removing mappable areas. So you are left with a fixed amount of video surface memory mappable by all clients all the time. If you actually wanted a direct rendered video solution here is a short list of missing parts (or at least they were missing last time I looked) 1) Completly dynamic DRM maps. I.e. at any time a video memory area can be added as a mappable region to the DRM and removed later without having fixed offsets/ids etc. 2) XvMC(ish) API to allow creation of Video "context" that hides all the DRM related stuff. Needs to allow you to allocate surfaces by type and size. Get direct access to the surfaces, and use the surfaces with some sort of video display device. I think #1 is the hard one. Last time I checked the DRM drivers were allocating fixed memory chunks at init rather than dynamically sharing memory with the rest of the X server at runtime. -Matt -----Original Message----- From: Michel Dänzer [mailto:michel@;daenzer.net] Sent: Wednesday, November 06, 2002 2:53 PM To: Billy Biggs Cc: [EMAIL PROTECTED]; Elladan Subject: [Xpert]Re: But *why* no vblank? On Mit, 2002-11-06 at 17:39, Billy Biggs wrote: > Michel Dänzer ([EMAIL PROTECTED]): > > > > It would be preferable in general for video apps, though, to provide > > > a DRM-based api to use the overlay buffer, too. Like, a DRM-Xv. > > > For desktop use, the X11 context switch may be fairly acceptable > > > with something like XSYNC, but to achieve really excellent quality > > > (eg, suitable for output to a TV/broadcast/etc.) in, say, a video > > > player, a direct API would be nicer. > > > > If I'm not mistaken that's what XvMC is for. > > No, XvMC is an API to hardware motion compensation, basically for > hardware MPEG decoding. Don't let the name mislead you. Sure, motion compensation was probably the initial motivation, but my understanding from reading posts about it on Xpert (Mark or someone please correct me if I'm wrong) is that it supports non-MC surfaces, so it's basically a beefed up Xv which supports MC and direct rendering. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
