From patchwork Thu Sep 3 09:44:38 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 45331 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n839fsep028889 for ; Thu, 3 Sep 2009 09:41:54 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754796AbZICJlu (ORCPT ); Thu, 3 Sep 2009 05:41:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754519AbZICJlu (ORCPT ); Thu, 3 Sep 2009 05:41:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8073 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754764AbZICJlt (ORCPT ); Thu, 3 Sep 2009 05:41:49 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n839fouD004024; Thu, 3 Sep 2009 05:41:50 -0400 Received: from localhost.localdomain (vpn-10-53.str.redhat.com [10.32.10.53]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n839fl7c001560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 05:41:49 -0400 Message-ID: <4A9F9006.6020203@hhs.nl> Date: Thu, 03 Sep 2009 11:44:38 +0200 From: Hans de Goede User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090806 Fedora/3.0-3.7.b3.fc12 Thunderbird/3.0b3 MIME-Version: 1.0 To: Simon Farnsworth CC: Linux Media Mailing List Subject: Re: libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together References: <4A9E9E08.7090104@onelan.com> <4A9EAF07.3040303@hhs.nl> <4A9F89AD.7030106@onelan.com> In-Reply-To: <4A9F89AD.7030106@onelan.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org 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. 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(