> No, tvtime no longer hangs if no frames arrive, so there is no need for > this timeout handling. I'd strip it out, which can be done in a separate > patch.
Did you actually try it? Do you have some patches to tvtime which aren't upstream? I wrote the comment in question (and added the associated code). The issue is that tvtime does *everything* in a single thread (except the recent ALSA audio work), that includes servicing the video/vbi devices as well as the user interface. That thread blocks on a DQBUF ioctl until data arrives, and thus if frames are not being delivered it will hang the entire tvtime user interface. Now you can certainly argue that is a bad design decision, but it's been that way for 15+ years, so we can't break it now. Hence why I generate dummy frames on a timeout if the decoder isn't delivering video. Unfortunately the au8522 doesn't have a free running mode (i.e. blue screen if no video), which is why most of the other devices work fine (decoders by Conexant, NXP, Trident, etc all have such functionality). Don't get me wrong - I *hate* that I had to put that timer crap in the driver, but it was necessary to be compatible with one of the most popular applications out there. In short, that code cannot be removed. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
