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
next prev parent reply other threads:[~2011-07-22 21:22 UTC|newest]
Thread overview: 10+ 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-07-27 17:15 ` Anca Emanuel
2011-07-27 18:33 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.