Re: [Workshop-2011] RFC: V4L2 API ambiguities

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 08/13/2012 04:52 PM, Hans Verkuil wrote:
> On Mon August 13 2012 15:13:34 Hans de Goede wrote:
>> Hi,
>>
>> <snip>
>>
>>> 5) How to handle tuner ownership if both a video and radio node share the same
>>>      tuner?
>>>
>>>      Obvious rules:
>>>
>>>      - Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will change owner
>>>        or return EBUSY if streaming is in progress.
>>
>> That won't work, as there is no such thing as streaming from a radio node,
>
> There is, actually: read() for RDS data and alsa streaming (although that might
> be hard to detect in the case of USB audio).
>
>> I suggest we go with the simple approach we discussed at our last meeting in
>> your Dutch House: Calling S_FREQ, S_TUNER, S_MODULATOR or S_HW_FREQ_SEEK will
>> make an app the tuner-owner, and *closing* the device handle makes an app
>> release its tuner ownership. If an other app already is the tuner owner
>> -EBUSY is returned.
>
> So the ownership is associated with a filehandle?

Yes, that is how it works for videobuf streams too, right? The only difference
being that with videobuf streams there is an expilict way to release the ownership,
where as for tuner ownership there is none, so the ownership is released on device
close.

>
>>
>>>      - Ditto for STREAMON, read/write and polling for read/write.
>>
>> No, streaming and tuning are 2 different things, if an app does both, it
>> will likely tune before streaming, but in some cases a user may use a streaming
>> only app together with say v4l2-ctl to do the actual tuning. I think keeping
>> things simple here is key. Lets just treat the "tuner" and "stream" as 2 separate
>> entities with a separate ownership.
>
> That would work provided the ownership is associated with a filehandle.

Right.

>
>>
>>>      - Ditto for ioctls that expect a valid tuner configuration like QUERYSTD.
>>
>> QUERY is a read only ioctl, so it should not be influenced by any ownership, nor
>> imply ownership.
>
> It is definitely influenced by ownership, since if the tuner is in radio mode,
> then it can't detect a standard. Neither is this necessarily a passive call as
> some (mostly older) drivers need to switch the receiver to different modes in
> order to try and detect the current standard.

Hmm, then I guess that this call should fail with EBUSY if:
The tuner is owned by another app *and*
1) The tuner is in radio mode; or
2) The tuner is in tv mode *and* doing QUERYSTD requires "prodding" the device

<snip>

Regards,

Hans