Gerd Knorr wrote:
>
> > So, somewhere between 0.4.0 and 0.6.3 someone made a bitmap version. And
> > somewhere after 0.6.3 and the kernel driver it was made the default and the
> > non-bitmap version was removed.
>
> Someone (Alan?) wrote the bitmapped version for the kernel and Ralph merged
> it back into bttv 0.6.x (and probably added the comment about it being slow).
>
> As I started porting bttv to the new i2c layer and maintaining the 0.7.x
> versions one of the first actions was to kill one of the two clipping
> code versions. I decided to go with the bitmapped version because the
> code was robust and easy to understand. As the clipping usually does'nt
> change that often performance is'nt that critical IMHO. Also the bitmapped
> clipping code is much faster in current versions than in 0.6.x.
>
> > As Alex Bakaev said, there is no need for the risc buffers to be contiguous.
> > The kernel could allocate a small 4k buffer for each field's program. If the
> > buffer fills up, allocate another 4k and chain the program from the first
> > buffer to the next with a JUMP instruction.
>
> Maybe I do it this way some day. I plan to rewrite the risc code generation
> and capture handling completely. There is alot of historical cruft in the
> driver which predates the v4l API. Also the kernel has much better support
> for PCI DMA these days (see kiobufs + dma-to-userspace, see
> Documentation/DMA-mapping.txt, have a look at btaudio.c). I think the ugly
> memory handling code can be killed now.
>
> Gerd
Just a quick comment on this thread: (from the bt848 pdf)
"WRITE, WRITEC and SKIP ... control the sequence of packed data written
to target memory on a byte resolution basis."
So there are no problems doing byte-aligned clips. I have tested this
myself (with bttv2), and it works perfectly (single pixel wide clips,
that is, but you obviously only get a small piece of the image before
running out of RISCMEM). I seem to remember looking at bttv's clipping
code once, and (at least at that stage), there were a number of possible
RISC memory overflows.
-justin
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
