Hello *, Gerd's explanation is a good starting point. Here are my 2 cents: 1) Handling VIDIOC_PREVIEW as a "low-priority capture" is good IMHO. While watching TV with my card, some other app may try to capture frames from another input without interfering to much. 2) We should make clear that the device contexts regards the following IOCTLs, too: a) S_INPUT / G_INPUT b) S_TUNER / G_TUNER (if there is a tuner on that input) c) S_FREQ / G_TUNER (if the freq can be set on the tuner) d) S_AUDIO / G_AUDIO (if there are multiple audio sources) e) QUERYCTRL / G_CTRL / S_CTRL -- this is perhaps the most critical thing. f) S_STD / G_STD Imagine something like this: I am watching TV on input 1 with tuner 1 on this input with freq X in PAL. I have a cron job with an app, that uses the same TV-card for surveillance purposes, say on input 2, with tuner 1 on input 2, with freq Y in NTSC. Both apps should be able to use the above IOCTLs without colliding with the other app. App1 should be able to set the values and then call VIDIOC_PREVIEW, App2 should be able to set the values, too and then simply call VIDIOC_STREAMON. If we don't handle this right, above example might not work. CU, Michael.
