Re: [V4L] bttv bitmap clipping, and bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



> 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

-- 
Protecting the children is a good way to get a lot of adults who cant
stand up for themselves.		-- seen in some sig on /.





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux