public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Hans de Goede <hdegoede@redhat.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: partial revert of "uvcvideo: set error_idx properly"
Date: Sun, 27 Jan 2013 12:06:29 -0200	[thread overview]
Message-ID: <20130127120629.2662ad60@redhat.com> (raw)
In-Reply-To: <201301251140.13707.hverkuil@xs4all.nl>

Em Fri, 25 Jan 2013 11:40:13 +0100
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On Fri January 25 2013 10:51:57 Hans de Goede wrote:
> > <modified the CC list to be more appropriate>
> > 
> > Hi,
> > 
> > On 12/25/2012 05:56 AM, Mauro Carvalho Chehab wrote:
> > 
> > > The pwc driver can currently return -ENOENT at VIDIOC_S_FMT ioctl. This
> > > doesn't seem right. Instead, it should be getting the closest format to
> > > the requested one and return 0, passing the selected format back to
> > > userspace, just like the other drivers do. I'm c/c Hans de Goede for him
> > > to take a look on it.
> > 
> > I've been looking into this today, and the ENOENT gets returned by
> > pwc_set_video_mode and through that by:
> > 1) Device init
> > 2) VIDIOC_STREAMON
> > 3) VIDIOC_S_PARM
> > 4) VIDIOC_S_FMT
> > 
> > But only when the requested width + height + pixelformat is an
> > unsupported combination, and it being a supported combination
> > already gets enforced by a call to pwc_get_size in
> > pwc_vidioc_try_fmt, which also gets called from pwc_s_fmt_vid_cap
> > before it does anything else.
> > 
> > So the ENOENT can only happen on some internal driver error,
> > I'm open for suggestions for a better error code to return in
> > this case.
> 
> Perhaps returning EINVAL but adding a WARN_ON would be a good compromise.
> 
> > What I did notice is that pwc_vidioc_try_fmt returns EINVAL when
> > an unsupported pixelformat is requested. IIRC we agreed that the
> > correct behavior in this case is to instead just change the
> > pixelformat to a default format, so I'll write a patch fixing
> > this.
> 
> There are issues with that idea in the case of TV capture cards, since
> some important apps (tvtime and mythtv to a lesser extent) assume -EINVAL
> in the case of unsupported pixelformats.
> 
> Webcam apps can't assume that since gspca never returned -EINVAL, so I
> think it should be OK to fix this in pwc, but Mauro may disagree.

It is known that both MythTV and tvtime have issues.

Well, I don't think that MythTV has webcam support. So, it will likely
fail with pwc anyway, as it doesn't have a tuner. So, webcam drivers don't
need to care with breaking anything on it.

Tvtime can work with webcams, if they provide a resolution that it is
compatible with it and if it supports UVYV or YUYV. This is not the case
of pwc, that seems to support only pwc proprietary formats and yuv420.

So, neither tvtime or MythTV currently works with pwc cameras.

However, the issue is a little more complex, as we don't really know if
there aren't any other applications that use a code similar to tvtime
or MythYV.

Regards,
Mauro

  parent reply	other threads:[~2013-01-27 14:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKbGBLiOuyUUHd+eEm+z=THEu57b2LSDFtoN9frXASZ5BG7Huw@mail.gmail.com>
     [not found] ` <CA+55aFxhXE8KbnjL7Nn3y0jd_wUFsdH6ZvsQ5EL+4cV3k3S4cg@mail.gmail.com>
     [not found]   ` <20121224213948.36514eca@redhat.com>
     [not found]     ` <20121225025648.5208189a@redhat.com>
2013-01-25  9:51       ` partial revert of "uvcvideo: set error_idx properly" Hans de Goede
2013-01-25 10:40         ` Hans Verkuil
2013-01-25 13:40           ` Hans de Goede
2013-01-25 13:42             ` Hans Verkuil
2013-01-27 13:57               ` Mauro Carvalho Chehab
2013-01-27 14:06           ` Mauro Carvalho Chehab [this message]
2013-01-28 10:04             ` Hans de Goede

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=20130127120629.2662ad60@redhat.com \
    --to=mchehab@redhat.com \
    --cc=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --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