> > of course,I need to take care that switching does not occur in the > > middle of an image. However, since my video inputs are not synchronized, > > I just switch from input to another at the end of the "capture 2 images" (and > > just after loading the new RISC instructions). > > datasheet != real world. 8-) But please don't let us argue about this... > > Ok, I see, you have already modified the bttv driver to achieve this and > you don't want to do the switching in the userland program anyway. I don't see the point in hacking the driver for this, IMHO it should be doable just fine with the driver as-is (with the mdelay commented maybe, it isn't needed and in bttv 0.8.x it is ifdef'ed out already). > > Right. It seems that the "switching" is done outside the bt878 core. So > > the grabbing RISC instructions are not aware of this. However, it sets > > the FDSR bit in the Interrupt Status sometimes (Fifo Data Stream > > Resynchronization). > > Switching and grabbing don't synchronize each other I suppose, ie. you > can switch the current input even if capturing is in progress. ... and if you do this you likely see the FDSR status bit set. The DMA engine has some scanline length / risc instruction mismatches due to the input switch and the re-syncronisation needed because of that. Just start streaming capture (with double-buffering and stuff ...), switch input right after the SYNC ioctl, throw away every second image which gets trashed due to the input switch, done. I doubt you get better results with a hacked driver. If you want to refine this, you can also check the HLOC status bit to see whenever the bt878 is synced or not. It is passed to userland in video_tuner->signal. > I though of "unsolvable" in the sense of "fast switching of several > inputs on most bt8x8 cards without modifying the driver and detecting in > a reliable way if the bt8x8 has itself synchronized to the new input". Use video_tuner->signal. > If you can find a way to detect if the bt8x8 has synchronized itself to > the new input, you could simply do something like this: after a > successful capture, stop the risc engine, check if it's synchronized, > start the risc engine with the next capture. The bt8x8 should then start > to capture with the beginning of the next valid frame. Of course you > cannot tell how long the time between "stop, check, start, beginning of > capture" lasts and how much frames the start/stop cycle will cost. I would never stop the risc engine exactly to avoid losing frames due to the start/stop cycle. Gerd -- You can't please everybody. And usually if you _try_ to please everybody, the end result is one big mess. -- Linus Torvalds, 2002-04-20
