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: 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