Re: [PATCH 3/3] [media] tvp5150: Migrate to media-controller framework and add video format detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 03, 2011 at 04:36:44PM -0300, Mauro Carvalho Chehab wrote:
> Em 03-10-2011 16:01, Sakari Ailus escreveu:
> > On Mon, Oct 03, 2011 at 03:53:54PM -0300, Mauro Carvalho Chehab wrote:
> >> Yes, you're right. I should not try to answer emails when I'm lazy enough to not
> >> look in to the code ;)
> >>
> >> Anyway, the thing is that V4L2 API has enough support for auto-detection. There's
> >> no need to duplicate stuff with MC API.
> > 
> > It's not MC API but V4L2 subdev API. No-one has proposed to add video
> > standard awareness to the Media controller API. There's no reason to export
> > a video node in video decoder drivers... but I guess you didn't mean that.
> > 
> > Would implementing ENUM/G/S_STD make sense for the camera ISP driver, that
> > has nothing to do with any video standard?
> 
> This is an old discussion, and we never agreed on that. Some webcam drivers 
> implement those ioctls. Others don't. Both cases are compliant with the
> current specs. In the past, several userspace applications used to abort if those
> ioctl's weren't implemented, but I think that this were fixed already there.
> 
> As I said, we should define a per-device type profile in order to enforce that
> all devices of the same type will do the same. We'll need man power to fix the
> ones that aren't compliant, and solve the userspace issues. Volunteers needed.
> 
> There's one point to bold on it: devices that can have either an analog input
> or a digital input will likely need to implement ENUM/G/S_STD for both, as
> userspace applications may fail, if the ioctl's are disabled depending on the
> type of input. We had to implement them on several drivers, due to that.

My disguised question behind this was actually that would a driver need to
implement an ioctl that has no relevance to the driver itself at all but
only to support another driver, yet the first driver might not have enough
information to properly implement it?

It may be sometimes necessary but I would like to avoid that if possible
since it complicates even more drivers which already are very complex.

> > If you have two video decoders
> > connected to your system, then which one should the ioctls be redirected to?
> > What if there's a sensor and a video decoder? And how could the user know
> > about this?
> 
> When an input is selected (either via the V4L2 way - S_INPUT or via the MC/subdev
> way, there's just one video decoder or sensor associated to the corresponding
> V4L2 node).
> 
> > It's the same old issues again... let's discuss this in the Multimedia
> > summit.
> 
> We can discuss more at the summit, but we should start discussing it here, as
> otherwise we may not be able to go into a consensus there, due to the limited
> amount of time we would have for each topic.

Sounds good to me, but sometimes face-to-face discussion just is not
replaceable.

-- 
Sakari Ailus
e-mail: sakari.ailus@xxxxxx	jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux