An article on the media controller

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

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

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.

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

Hans Verkuil - video4linux developer - sponsored by Cisco

Hi Jonathan,

Thanks a lot for the article.

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).

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

Thank you in advance for the review.

Best regards,

Laurent Pinchart