> 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). First point: /dev/video0 cannot be open() multiple times (ok, I've done a master/slave grabber to solve that issue, but that's a lot of pain). Second point: Userland switching has no control over scheduling. So, you're right, it works. But anytime I run an infinite loop for instance, it no longer works. > 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. Thanks for the HLOC. I'll check for that. > I would never stop the risc engine exactly to avoid losing frames due to > the start/stop cycle. > > Gerd Right. Stoppping the DMA wasted too much images I think. But back to my first questions: - why writing 00 to MUXSEL ? - does this mean that input 3 (coresponding to MUXSEL=00) has a special status ? - mdelay() is not needed at all ? In fact, I've hardcoded the input switching code in the middle of bttv_irq, where I don't like the "hidden" mdelay() ... Thanks again. Benoit
