An article on the media controller

An article on the media controller

[Jonathan Corbet]

I've just spent a fair while looking through the September posting of
the media controller code (is there a more recent version?).  The
result is a high-level review which interested people can read here:

	http://lwn.net/SubscriberLink/415714/1e837f01b8579eb7/

Most people will not see it for another 24 hours or so; if there's
something I got radically wrong, I'd appreciate hearing about it.

The executive summary is that I think this code really needs some
exposure outside of the V4L2 list; I'd encourage posting it to
linux-kernel.  That could be hard on plans for a 2.6.38 merge (or, at
least, plans for any spare time between now and then), but the end
result might be better for everybody.

I have some low-level comments too which were not suitable for the
article.  I'll be posting them here, but I have to get some other
things done first.

Thanks,

jon

Re: An article on the media controller

[Andy Walls]

On Tue, 2010-11-16 at 15:18 -0700, Jonathan Corbet wrote:
> I've just spent a fair while looking through the September posting of
> the media controller code (is there a more recent version?).  The
> result is a high-level review which interested people can read here:
> 
> 	http://lwn.net/SubscriberLink/415714/1e837f01b8579eb7/

As I understand it, the current code patches are a subset of the
ultimate desired/planned  functionality. 

So I would need to think about this statement:

"Given that the configuration interface changes a single bit at a time,
there is no need for the sort of transactional functionality that can
make ioctl() preferable to sysfs."

It may very well apply to the current patches, but I'd have to think
about if multiple items would need to be set or queried at one time.

You might just want to add the qualifier "current" when referring to the
interface changes.

Regards,
Andy

> Most people will not see it for another 24 hours or so; if there's
> something I got radically wrong, I'd appreciate hearing about it.
> 
> The executive summary is that I think this code really needs some
> exposure outside of the V4L2 list; I'd encourage posting it to
> linux-kernel.  That could be hard on plans for a 2.6.38 merge (or, at
> least, plans for any spare time between now and then), but the end
> result might be better for everybody.
> 
> I have some low-level comments too which were not suitable for the
> article.  I'll be posting them here, but I have to get some other
> things done first.
> 
> Thanks,
> 
> jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: An article on the media controller

[Hans Verkuil]

On Tuesday, November 16, 2010 23:18:02 Jonathan Corbet wrote:
> I've just spent a fair while looking through the September posting of
> the media controller code (is there a more recent version?).  The
> result is a high-level review which interested people can read here:
> 
> 	http://lwn.net/SubscriberLink/415714/1e837f01b8579eb7/
> 
> Most people will not see it for another 24 hours or so; if there's
> something I got radically wrong, I'd appreciate hearing about it.

Just two points, really: we do not expect generic applications to use this
API other than for determining the default device nodes. E.g. if a device
has 5 video nodes and two alsa nodes, then one video and one alsa node will
be marked as the default and applications are supposed to open those. This
will allow apps to find the right device nodes for capturing.

The more advanced functionality is expected to be used by custom applications
specific to that hardware. I also expect to see either libv4l2 or gstreamer
plugins or libraries created for specific SoCs that use this API. The hardware
that the MC describes is simply too varied and unpredictable to ever be able
to use it with just the MC data. The main purpose is to at least be able to
expose the full functionality to userspace.

The other point is the same that Andy made: we expect that the API will change
a bit allowing for atomically changing multiple links at the same time. Not
something that sysfs can handle (not without some horrible hacks at least).

I also think sysfs is a mess and horrible to use, but that's just my opinion.
 
> The executive summary is that I think this code really needs some
> exposure outside of the V4L2 list; I'd encourage posting it to
> linux-kernel.  That could be hard on plans for a 2.6.38 merge (or, at
> least, plans for any spare time between now and then), but the end
> result might be better for everybody.

I agree with that. It was always designed for generic use, but on the other
hand we can't postpone it for too long since V4L really needs this.

Thanks for the article!

Regards,

	Hans

> I have some low-level comments too which were not suitable for the
> article.  I'll be posting them here, but I have to get some other
> things done first.
> 
> Thanks,
> 
> jon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco

Re: An article on the media controller

[Laurent Pinchart]

Hi Jonathan,

On Tuesday 16 November 2010 23:18:02 Jonathan Corbet wrote:
> I've just spent a fair while looking through the September posting of
> the media controller code (is there a more recent version?).  The
> result is a high-level review which interested people can read here:
> 
> 	http://lwn.net/SubscriberLink/415714/1e837f01b8579eb7/

Thanks a lot for the article.

> Most people will not see it for another 24 hours or so; if there's
> something I got radically wrong, I'd appreciate hearing about it.

Here are a few comments:

- Second paragraph: s/lens distortion/lens shading/

- Fifth paragraph: entities can have no bad if no data flows in or out of them 
(think of a flash controller for instance,  it needs to be configured, 
associated with a sensor, but is not involved in any media data flow). The 
pads represent connection points for data flows (usually media data), not for 
software configuration.

- Tenth paragraph: there's no end-user application available at the moment, 
but we already have a command line test application 
(http://git.ideasonboard.org/?p=media-ctl.git;a=summary) and a GStreamer 
element (called subdevsrc, available from http://meego.gitorious.org/maemo-
multimedia/gst-nokia-videosrc).

> The executive summary is that I think this code really needs some
> exposure outside of the V4L2 list; I'd encourage posting it to
> linux-kernel.  That could be hard on plans for a 2.6.38 merge (or, at
> least, plans for any spare time between now and then), but the end
> result might be better for everybody.

I agree that the more developers who will look at the code, the more ideas we 
will get. That might get difficult to manage though :-) I'll cross-post the 
next version of the patches.

Regarding sysfs, I won't repeat Hans' and Andy's arguments, but I don't think 
it would be a very good match. The API would get much more difficult to use 
and would require lany times more system calls. While the media controller 
solves a problem that can appear similar to our current power management and 
clock routing issues, I'm not sure a common API would make sense. That would 
be like arguing that DirectShow should be used for hard disk power management 
in Windows :-)

> I have some low-level comments too which were not suitable for the
> article.  I'll be posting them here, but I have to get some other
> things done first.

Thank you in advance for the review.

-- 
Best regards,

Laurent Pinchart