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.
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
