[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 #16 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2014-08-29 20:23:17 UTC ---
(In reply to comment #15)
> 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.

Actually there is a subtle difference in what I had in mind, I would probe
REQBUFS(0) for all case first (as we do now), then if the flags are 0 (no
capabilities), I'd warn and set the MMAP capability. As we are assuming an old
videobuf driver, assuming no createbuf support (don't know who had a driver
with that implemented to be honest).

It's up to you, I'm compiling/sanity checking the two others before merging
right now, I can deal with that third patch if you prefer.

-- 
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.