Peter A Kaczowka writes: > Video4Linux (or at least the bttv/Bt848 driver) supports setting a clipping > bitmap, where a 1 in the bitmap means omit the video, a 0 means show the video. > This is apparently an undocumented feature; I found it by reading the source. > What is documented is that you can set a list of clipping rectangles, but the > driver always turns those into a clipping bitmap anyway. > > There's no documentation (that I know of) but there is this in linux/videodev.h: > > #define VIDEO_CLIP_BITMAP -1 > /* bitmap is 1024x625, a '1' bit represents a clipped pixel */ > #define VIDEO_CLIPMAP_SIZE (128 * 625) > > You can set the clipping bitmap by setting "clipcount" in struct video_window > to VIDEO_CLIP_BITMAP, and then by pointing "clips" to the actual bits. The > bitmap is 1024 x 625, or VIDEO_CLIPMAP_SIZE in bytes. The bitmap is little > endian; you can use bitmaps you get back from XGetImage on XFree86. > > Neat feature, but it does have limitations and bug(s). There seems to be a > limit on how "narrow" the clipping can be. If you have a scanline in the > bitmap with every-other bit on, it will generally not accurately clip to it. > There is also a nasty limit on how complex the total clipping shape can be. > For example, if you use a half-tone stipple pattern (every-other bit on, > staggered lines) for the whole screen Video4Linux will lock up the machine, > requiring a reboot. > > Now my question: does anyone out there have any experience with these problems? > Is there a fix for the driver? Even knowing what the actual DMA engine > limitations are would be useful. The Bt848 hardware does not support a clipping bitmap directly. What gets DMAd to screen/memory is programmed via a RISC engine. You can basically tell it to "Write N bytes to ADDR", "SKIP N bytes", "JUMP to instruction N" (usually at the end of a frame to start over). The commands also only process one 32Bit DWORD of data at a time. Windows should start on DWORD boundaries. If single bytes are to be skipped you have to use a WRITE but with masks for the skipped bytes set. Clipping in 24 bit graphics modes is a real pain! The bitmap now has to be translated to such RISC commands. The more complex the bitmap is, the more commands are generated. In the worst case, there would be more RISC commands (each of those has at least 32 bits ) than bytes to a frame. These RISC commands are also transferred via DMA to the Bt848 in real time! I don´t know where the hardware limit for RISC command DMAs per frame are, but long before that you probably run out of the allocated space for RISC commands in the driver. For the current state of the clipping code and its exact limitations you´ll have to ask Gerd Knorr, who is more up to date with the bttv driver. Other PCI bridges like the Philips SAA7146 and, AFAIR, some ZORAN chips provide bitmap clipping directly in hardware. This even allows one to change the bitmap in real time without much CPU usage. But those chips need an external TV decoder chip and they did not become as widely used as the Bt848. Ralph
