libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together

Commit Message

Hans de Goede Sept. 3, 2009, 9:44 a.m. UTC

Hi,

On 09/03/2009 11:17 AM, Simon Farnsworth wrote:
> Hans de Goede wrote:
>> Hi,
>>
>> On 09/02/2009 06:32 PM, Simon Farnsworth wrote:
>>> I have a Hauppauge HVR1600 for NTSC and ATSC support, and it appears to
>>> simply not work with libv4l2, due to lack of mmap support. My code works
>>> adequately (modulo a nice pile of bugs) with a HVR1110r3, so it appears
>>> to be driver level.
>>>
>>> Which is the better route to handling this; adding code to input_v4l to
>>> use libv4lconvert when mmap isn't available, or converting the cx18
>>> driver to use mmap?
>>>
>>
>> Or modify libv4l2 to also handle devices which can only do read. There have
>> been some changes to libv4l2 recently which would make doing that feasible.
>>
> Roughly what would I need to do to libv4l2?
>
> I can see four new cases to handle:
>
> 1) driver supports read(), client wants read(), format supported by
> both. Just pass read() through to the driver.
>
>
> 3) As 1, but needs conversion. read() into a temporary buffer, convert
> with libv4lconvert (I think this needs a secondary buffer), and supply
> data from the secondary buffer to read()
>

Ok,

That was even easier then I thought it would be. Attached is a patch
(against libv4l-0.6.1), which implements 1) and 3) from above.

Please give this a try.

Regards,

Hans



>>> If it's a case of converting the cx18 driver, how would I go about doing
>>> that? I have no experience of the driver, so I'm not sure what I'd have
>>> to do - noting that if I break the existing read() support, other users
>>> will get upset.
>>
>> I don't believe that modifying the driver is the answer, we need to either
>> fix this at the libv4l or xine level.
>>
>> I wonder though, doesn't the cx18 offer any format that xine can handle
>> directly?
>>
> Not sensibly; it offers HM12 only, and Xine needs an RGB format, YV12,
> or YUYV. With a lot of rework, I could have the cx18 encode video to
> MPEG-2, then have Xine decode the resulting MPEG-2 stream, but this
> seems like overkill for uncompressed video. I could also teach Xine to
> handle HM12 natively, but that would duplicate effort already done in
> libv4l2 and libv4lconvert, which seems a bit silly to me.

Patch

diff -r 88a9c2ed612e v4l2-apps/libv4l/libv4l2/libv4l2.c
--- a/v4l2-apps/libv4l/libv4l2/libv4l2.c	Wed Sep 02 11:25:10 2009 +0200
+++ b/v4l2-apps/libv4l/libv4l2/libv4l2.c	Thu Sep 03 11:43:15 2009 +0200
@@ -526,10 +526,9 @@ 
     return -1;
   }
 
-  /* we only add functionality for video capture devices, and we do not
-     handle devices which don't do mmap */
+  /* we only add functionality for video capture devices */
   if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE) ||
-      !(cap.capabilities & V4L2_CAP_STREAMING))
+      !(cap.capabilities & (V4L2_CAP_STREAMING|V4L2_CAP_READWRITE))
     return fd;
 
   /* Get current cam format */
@@ -564,6 +563,8 @@ 
   devices[index].flags = v4l2_flags;
   if (cap.capabilities & V4L2_CAP_READWRITE)
     devices[index].flags |= V4L2_SUPPORTS_READ;
+  if (!(cap.capabilities & V4L2_CAP_STREAMING))
+    devices[index].flags |= V4L2_USE_READ_FOR_READ;
   if (!strcmp((char *)cap.driver, "uvcvideo"))
     devices[index].flags |= V4L2_IS_UVC;
   devices[index].open_count = 1;
@@ -571,7 +572,7 @@ 
   devices[index].dest_fmt = fmt;
 
   /* When a user does a try_fmt with the current dest_fmt and the dest_fmt
-     is a supported one we will align the resulution (see try_fmt for why).
+     is a supported one we will align the resolution (see try_fmt for why).
      Do the same here now, so that a try_fmt on the result of a get_fmt done
      immediately after open leaves the fmt unchanged. */
   if (v4lconvert_supported_dst_format(