On Mon, 7 Mar 2005, Greg Stark wrote: > Mark Vojkovich <mvojkovi@xxxxxxxxxxx> writes: > > > I'm assuming by not working, it looks like it's working from a client > > point of view, but the overlay just never shows. > > Well, I imagine that's the case. Or else mplayer is just failing to detect the > failure. Is there a canonical test program that would be guaranteed to be > handling error handling properly? I believe mplayer handles this correctly. > > > It's conceivable that overlay fifo underflow in the chip could cause the > > overlay to stop functioning. > > Well I don't see any errors logged about "fifo underflow". Matrox might not even have a register to check if it's occuring. > > This is why I'm not a hardware guy. When you have no visibility to what's > going on how are you supposed to debug anything? > > > I've seen it happen on some NVIDIA cards. If this is happening, the > > OverclockMem option might help. > > > Apps are supposed to grab the port when they use it. If another app > > tries to use it, they will fail to access the grabbed port. > > Yeah, if I try to run a second mplayer I get: > > Xv: could not grab port 61 > Could not find free Xvideo port - maybe another process is already using it. > > So that's not exactly it. > > I noticed this in the mga(4) man page: > > Option "TexturedVideo" "boolean" > This has XvImage support use the texture engine rather than the > video overlay. This option is only supported by G200 and later > chips, and only at 16 and 32 bits per pixel. Default: off. > > Does this allow for more than a single port? There's no reason the card would > be limited to a single texture after all, it handles hundreds during a quake > game. Yes, hardcoded to 32. The performance of that option is lower because it actually has to render those pixels rather than just overlay them, but it should eliminate any problems with the HW overlay flaking out. Mark. _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86