[Bug 758703] v4l2src: gst_v4l2_set_attribute warning messages cause infinite loop with .dot dump

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758703

--- Comment #7 from Dimitrios Katsaros <patcherwork at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #5)

I think I didn't explain some stuff so let me try and make things a little more
clear :)

> In any case I mark this patch as need work for now, as it does not seem to
> take into account (or in fact try to figure-out) why a warning is currently
> posted on the bus. 

GST_ELEMENT_WARNING posts messages to the bus. from the doc:

Utility function that elements can use in case they encountered a non-fatal
data processing problem. The pipeline will post a warning message and the
application will be informed.

> It also does not explain how a warning on the bus least
> to another. 

The GST_DEBUG_BIN_TO_DOT_FILE* functions iterate through the components of each
element and query all the readable properties for their values. gst-launch has
calls to the GST_DEBUG_BIN_TO_DOT_FILE_WITH_TS functions in multiple cases,
e.g. state transitions, warnings and errors. Say that the pipeline transitions
from NULL to READY, the following steps will happen:

1) GST_DEBUG_BIN_TO_DOT_FILE_WITH_TS is called, iterating over the pipeline
elements.

2) v4l2src properties are retrieved. Amongst the properties are Hue,
Saturation, Brightness and Contrast. The v4l2device calls
gst_v4l2_set_attribute to retrieve the control value.

3) the control is not implemented for the device being targeted so
gst_v4l2_set_attribute fails. It calls GST_ELEMENT_WARNING, posing a warning
message on the bus. 

4) gst_launch handles the message. It is a warning, which calls
GST_DEBUG_BIN_TO_DOT_FILE_WITH_TS to save a dump of the state that caused the
warning. we are back at 1).

> Finally, you said the spec allow returning -EINVAL, why do you
> try to handle it (also, reference to the spec please) ?

I am not sure what you mean here since I am not trying to handle it. The doc
for VIDIOC_G_CTRL(http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-ctrl.html)
states: "When the id is invalid drivers return an EINVAL error code."

And if you look at the doc for VIDIOC_QUERYCTRL
(http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-queryctrl.html):

"Drivers may return EINVAL if a control in this range is not supported"

So it isn't invalid if a driver chooses to return EINVAL if a control is not
provided. 

> Can you provide a backtrace (a part of it) that show where the infinite loop
> starts, and where it goes through.

I will add a patch for vivid that causes the behavior

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.