Hello Gerd, > > 2) We should make clear that the device > > contexts regards the following IOCTLs, too: > > > > a) S_INPUT > > b) S_TUNER > > c) S_FREQ > > d) S_AUDIO > > e) QUERYCTRL > > f) S_STD > > IMHO they belong into the device context to. > > New problem: How to handle sound? For the video-related settings it is > quite clear: The driver will set them if the application goes to use the > video hardware, i.e. capture image(s) with read() or STREAMON+friends. > > For audio it is'nt that obvious. There is - for example - no need to > touch TV sound if you switch the video input to the camera temporarely to > capture a image for your webcam... IMHO there should be a "priority" like this: 1) streaming-capture 2) read()-capture 3) overlay This means that 2) interrupts 3) and 1) interrupts the 2) and 3). The default behaviour for audio of 1) + 3) is, that they switch the audio source, too. 2) should not (in it's default behaviour) switch the audio source, since read() is not really useful for streaming capture and therefore does not need the audio signal. (Especially in your "multiple open"-draft you state that for read() the driver should set up the hardware, make one capture and then set back the settings -- with this, "streaming" is not possible anyway.) Of course, there should be some kind of flag that overrides the default settings. > Gerd CU, Michael.
