From patchwork Thu Sep 3 10:37:19 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Farnsworth X-Patchwork-Id: 45335 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 n83AbPRk002095 for ; Thu, 3 Sep 2009 10:37:25 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754859AbZICKhU (ORCPT ); Thu, 3 Sep 2009 06:37:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754857AbZICKhU (ORCPT ); Thu, 3 Sep 2009 06:37:20 -0400 Received: from claranet-outbound-smtp03.uk.clara.net ([195.8.89.36]:37450 "EHLO claranet-outbound-smtp03.uk.clara.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754764AbZICKhT (ORCPT ); Thu, 3 Sep 2009 06:37:19 -0400 Received: from host217-35-101-6.in-addr.btopenworld.com ([217.35.101.6]:51461 helo=f8simon.office.onelan.co.uk) by relay03.mail.eu.clara.net (relay.clara.net [213.253.3.43]:1025) with esmtpa (authdaemon_plain:simon.farnsworth@onelan.co.uk) id 1Mj9gu-0000QI-A9 (Exim 4.69) (return-path ); Thu, 03 Sep 2009 10:37:20 +0000 Message-ID: <4A9F9C5F.9000007@onelan.com> Date: Thu, 03 Sep 2009 11:37:19 +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> <4A9F98BA.3010001@onelan.com> In-Reply-To: <4A9F98BA.3010001@onelan.com> Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Simon Farnsworth wrote: > 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. > There is indeed something obviously wrong; at line 315 of libv4l2.c, we expand the buffer we read into, then ask for that many bytes. fixes it for me. I appear to lose colour after a few seconds of capture, which I shall chase further. 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:32:40 2009 +0100 @@ -326,7 +326,7 @@ } do { - result = SYS_READ(devices[index].fd, devices[index].readbuf, buf_size); + result = SYS_READ(devices[index].fd, devices[index].readbuf, devices[index].dest_fmt.fmt.pix.sizeimage); if (result <= 0) { if (result && errno != EAGAIN) { int saved_err = errno;