From patchwork Thu Sep 3 10:21:46 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Farnsworth X-Patchwork-Id: 45334 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 n83ALrF7000354 for ; Thu, 3 Sep 2009 10:21:53 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754854AbZICKVt (ORCPT ); Thu, 3 Sep 2009 06:21:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754838AbZICKVt (ORCPT ); Thu, 3 Sep 2009 06:21:49 -0400 Received: from claranet-outbound-smtp00.uk.clara.net ([195.8.89.33]:41775 "EHLO claranet-outbound-smtp00.uk.clara.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754821AbZICKVs (ORCPT ); Thu, 3 Sep 2009 06:21:48 -0400 Received: from host217-35-101-6.in-addr.btopenworld.com ([217.35.101.6]:43357 helo=f8simon.office.onelan.co.uk) by relay00.mail.eu.clara.net (relay.clara.net [213.253.3.40]:1025) with esmtpa (authdaemon_plain:simon.farnsworth@onelan.co.uk) id 1Mj9Rr-00031M-0X (Exim 4.69) (return-path ); Thu, 03 Sep 2009 10:21:49 +0000 Message-ID: <4A9F98BA.3010001@onelan.com> Date: Thu, 03 Sep 2009 11:21:46 +0100 From: Simon Farnsworth User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Hans de Goede 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> <4A9F9006.6020203@hhs.nl> In-Reply-To: <4A9F9006.6020203@hhs.nl> Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hans de Goede wrote: > 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. > I applied it to a clone of your HG repository, and had to make a minor change to get it to compile. I've attached the updated patch. It looks like the read() from the card isn't reading entire frames ata a time - I'm using a piece of test gear that I have to return in a couple of hours to send colourbars to it, and I'm seeing bad colour, and the picture moving across the screen. I'll try and chase this, see whether there's something obviously wrong. The repository I went against was http://linuxtv.org/hg/~hgoede/libv4l/ identified as: $ hg identify c51a90c0f62f+ tip diff -r c51a90c0f62f v4l2-apps/libv4l/libv4l2/libv4l2.c --- a/v4l2-apps/libv4l/libv4l2/libv4l2.c Tue Sep 01 10:03:27 2009 +0200 +++ b/v4l2-apps/libv4l/libv4l2/libv4l2.c Thu Sep 03 11:17:05 2009 +0100 @@ -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(