public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ondrej Zary <linux@rainbow-software.org>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Joerg Heckenbach <joerg@heckenbach-aw.de>,
	Dwaine Garden <dwainegarden@rogers.com>,
	linux-media@vger.kernel.org,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: [PATCH] [resend] usbvision: disable scaling for Nogatech MicroCam
Date: Fri, 22 Jul 2011 23:22:02 +0200	[thread overview]
Message-ID: <201107222322.07843.linux@rainbow-software.org> (raw)
In-Reply-To: <CAGoCfiwqzs70A26WgN2pJJvz2aDzY9siOcTuOCkYm3nDHB=J1Q@mail.gmail.com>

On Friday 22 July 2011 22:06:59 Devin Heitmueller wrote:
> On Fri, Jul 22, 2011 at 4:00 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> > Scaling causes bad artifacts (horizontal lines) with compression at least
> > with Nogatech MicroCam so disable it (for this HW).
> >
> > This also fixes messed up image with some programs (Cheese with 160x120,
> > Adobe Flash). HW seems to support only image widths that are multiple of 64
> > but the driver does not account that in vidioc_try_fmt_vid_cap(). Cheese
> > calls try_fmt with 160x120, succeeds and then assumes that it really gets
> > data in that resolution - but it gets 128x120 instead. Don't know if this
> > affects other usbvision devices, it would be great if someone could test it.
> >
> > Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
> >
> > diff -urp linux-2.6.39-rc2-/drivers/media/video/usbvision//usbvision-video.c linux-2.6.39-rc2/drivers/media/video/usbvision/usbvision-video.c
> > --- linux-2.6.39-rc2-/drivers/media/video/usbvision//usbvision-video.c  2011-07-16 16:42:35.000000000 +0200
> > +++ linux-2.6.39-rc2/drivers/media/video/usbvision/usbvision-video.c    2011-07-16 16:36:43.000000000 +0200
> > @@ -924,6 +924,11 @@ static int vidioc_try_fmt_vid_cap(struct
> >        RESTRICT_TO_RANGE(vf->fmt.pix.width, MIN_FRAME_WIDTH, MAX_FRAME_WIDTH);
> >        RESTRICT_TO_RANGE(vf->fmt.pix.height, MIN_FRAME_HEIGHT, MAX_FRAME_HEIGHT);
> >
> > +       if (usbvision_device_data[usbvision->dev_model].codec == CODEC_WEBCAM) {
> > +               vf->fmt.pix.width = MAX_FRAME_WIDTH;
> > +               vf->fmt.pix.height = MAX_FRAME_HEIGHT;
> > +       }
> > +
> >        vf->fmt.pix.bytesperline = vf->fmt.pix.width*
> >                usbvision->palette.bytes_per_pixel;
> >        vf->fmt.pix.sizeimage = vf->fmt.pix.bytesperline*vf->fmt.pix.height;
> > @@ -952,6 +957,11 @@ static int vidioc_s_fmt_vid_cap(struct f
> >
> >        usbvision->cur_frame = NULL;
> >
> > +       if (usbvision_device_data[usbvision->dev_model].codec == CODEC_WEBCAM) {
> > +               vf->fmt.pix.width = MAX_FRAME_WIDTH;
> > +               vf->fmt.pix.height = MAX_FRAME_HEIGHT;
> > +       }
> > +
> >        /* by now we are committed to the new data... */
> >        usbvision_set_output(usbvision, vf->fmt.pix.width, vf->fmt.pix.height);
> >
> >
> > --
> > Ondrej Zary
> 
> Hello Ondrej,
> 
> Drivers are permitted to return a different resolution than what the
> application provided in the S_FMT call.  It is the responsibility of
> the application to look at the struct after the ioctl() call and if
> the values are not what it expects to then accommodate the change.
> 
> In other words, this sounds like a bug in Cheese.

Seems that this bug is widespread - the same problem appears also in guvcview
and adobe flash. I think that the driver is broken too - it should return
corrected resolution in TRY_FMT.

> Devin
> 



-- 
Ondrej Zary

  reply	other threads:[~2011-07-22 21:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-22 20:00 [PATCH] [resend] usbvision: disable scaling for Nogatech MicroCam Ondrej Zary
2011-07-22 20:06 ` Devin Heitmueller
2011-07-22 21:22   ` Ondrej Zary [this message]
2011-07-22 21:31     ` Devin Heitmueller
2011-07-22 21:44       ` Ondrej Zary
2011-07-27 15:03         ` Mauro Carvalho Chehab
2011-08-01 18:50           ` Ondrej Zary
2011-08-01 20:19             ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201107222322.07843.linux@rainbow-software.org \
    --to=linux@rainbow-software.org \
    --cc=dheitmueller@kernellabs.com \
    --cc=dwainegarden@rogers.com \
    --cc=hverkuil@xs4all.nl \
    --cc=joerg@heckenbach-aw.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox