[Bug 735660] v4l2: fix new v4l2 code not working with certain devices (regression)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=735660
  GStreamer | gst-plugins-good | 1.4.1

--- Comment #15 from Hans de Goede <jwrdegoede at fedoraproject.org> 2014-08-29 20:05:41 UTC ---
(In reply to comment #13)
> I'm not making an argument against your work, I really appreciate that you take
> the time to report and propose patches that fixes issue you have. This is blind
> review, and request for comment. I only rejected the third patch because it
> breaks (yes literally) other use case I'm aware of. The two other patches may
> be merged when I'm done going over all use cases I know (that includes trying
> to see if they help with related bugs, or would lead to more re-write later).

Ok, fair enough.

As I already indicated in comment #3 I've had my own doubts about the 3th patch
(note I did test it with a uvc webcam too, so it was not tested with a single
device, I've written and maintain quite a few webcam drivers).

So I think that we seem to be in agreement that the best way to deal with the
problem the 3th patch tries to address is to simply assume that if reqbufs(0)
fails for plain mmap buffers, that we're then dealing with one of the
"troublesome" devices, and just assume reqbufs mmap capability, (and no
createbufs capability).

This should be easy enough to write a patch for (with a big fat comment
explaining this workaround in the code), assuming that V4L2_CAP_STREAMING has
already been tested for when 
gst_v4l2_allocator_new gets called.

Is this assumption correct, and do you agree that this will be the best way to
fix this ?

If so then I can write and test a patch using this method.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.