I was wrong here. Turns out that I did not use Xvideo at all because of (my not understanding of) my weird setup. I had the bttv module as /dev/video0 and Xv port 69, the dvb-ttpci module as /dev/video1 and Xv port 70, and the Matrox backend scaler as Xv port 71. Swapping around the numbers and playing with xawtv options reveals that it seems to not use the port 71 at all, and "-c /dev/video1" turns off Xv anyway (RTFM :-()
Hehe, ok. 8-)
Now I've swapped the cards (logically) and made DVB the first Xv port, and now xawtv uses it properly. No broken images yet.
What remains is that I got these distortions (and the apparent off-by-one image location) only when using DVB, but the part which writes into memory was plain overlay mode.
In older version of my driver (and apparently in the version that was used to fork the DVB driver) the protection address (ie. the address the video dma never crosses) is not set up correctly.
In that case, there might be a small temporal gap between the update of the video window location and the update of the clipping rectangles. If you are moving the window below the bottom of the screen, chances are good that in this time gap the video dma writes to the memory "behind" the actual framebuffer.
I experienced this with older versions of my analog tv driver, too, but I have fixed this apparently (I hope).
Olaf
You can try this out and set the protection address permanently and see, if you can still reproduce the corruption.
CU Michael.
-- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
