On Fri, Oct 22, 2010 at 17:18, Mauro Carvalho Chehab <mche...@redhat.com> wrote:
> Em 06-09-2010 03:53, Marek Szyprowski escreveu:
>> From: Pawel Osciak <p.osc...@samsung.com>
>>
>> VIDIOC_STREAMON should return EBUSY if streaming is already active.
>>
>> Signed-off-by: Pawel Osciak <p.osc...@samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.p...@samsung.com>
>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
>> ---
>>  Documentation/DocBook/v4l/vidioc-streamon.xml |    7 +++++++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/DocBook/v4l/vidioc-streamon.xml 
>> b/Documentation/DocBook/v4l/vidioc-streamon.xml
>> index e42bff1..fdbd8d8 100644
>> --- a/Documentation/DocBook/v4l/vidioc-streamon.xml
>> +++ b/Documentation/DocBook/v4l/vidioc-streamon.xml
>> @@ -93,6 +93,13 @@ synchronize with other events.</para>
>>  been allocated (memory mapping) or enqueued (output) yet.</para>
>>       </listitem>
>>        </varlistentry>
>> +      <varlistentry>
>> +     <term><errorcode>EBUSY</errorcode></term>
>> +     <listitem>
>> +       <para><constant>VIDIOC_STREAMON</constant> called, but
>> +       streaming I/O already active.</para>
>> +     </listitem>
>> +      </varlistentry>
>>      </variablelist>
>>    </refsect1>
>>  </refentry>
>
> I'm in doubt about this patch. I don't see any problem on just return 0 if
> stream is active.
>
> Actually, I think that this patch may break some applications, as there are
> some cases where stream may start even without streamon (like via read() 
> method).


A quick grep over the media directory reveals that many drivers
(including videobuf_streamon) return EBUSY for some cases. This patch
was not intended to introduce something new to the API. I just wanted
to document an undocumented return value. How should the EBUSY return
be interpreted? Or should we get rid of it?

-- 
Best regards,
Pawel Osciak
--
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

Reply via email to