V4L2 mini-summit Sep 2009

From OMAPpedia

IMPORTANT: THIS IS UNDER CONSTRUCTION.

This wikipage provides details about the Video4Linux mini-summit held at Linux Plumbers Conference 2009 in Portland, Oregon, USA on 23-25 Sep, 2009.

Contents 1 Atendees 2 Problems to Solve 2.1 SoC complex video devices handling 2.2 Optimal buffer handling between video devices 2.3 Standard device to application events communication 2.4 Standard timings setting for video interfaces 3 Proposals 3.1 Media Controller 3.1.1 What is it? 3.1.2 Why is needed? 3.1.3 Restrictions 3.1.4 Concepts

Atendees

• Moderator: Hans Verkuil.
• V4L-dvb core devs:
  • Mike Krufky
  • Steven Toth
  • Andy Walls
  • Brandon Philips.
• Nokia:
  • Sakari Ailus
  • Laurent Pinchart
• Texas Instruments:
  • Vaibhav Hiremath
  • Murali Karicheri
  • Sergio Aguirre
  • Lajos Molnar
• Samsung:
  • Marek Szyprowsky
  • Tomasz Fujak
  • Jin-Sung Yang
• Intel:
  • Guru Raj
  • Xiaolin Zhang.

Problems to Solve

This were the objects for discussion during the 3 days the summit was held:

SoC complex video devices handling

Recent System on Chip solutions have several internal video processing blocks, like:

• Scalers
• Colorspace Converters
• Composers
• Statistic collection modules
• Etc

Currently, V4L2 doesn’t offer a good API for this, and the functionality of current implementations is very limited to a set of fixed combinations.

Obviously, the need for an extension of v4l2 API for this arises.

Optimal buffer handling between video devices

Usually, a video buffer is shared between:

• Camera driver.
• Display driver.
• DSP for image processing.

Two choices are currently available:

• User pointers
  • Pro: Zero copy
  • Con: No real way to keep cache coherency
• Kernel mmaped buffers
  • Pro: Cache coherency not a problem
  • Con: Needs memcpys! (more memory footprint)

Therefore, the need for an optimal handling arises to have the best of both options above in a clean way.

Standard device to application events communication

Complex multimedia devices require an smart way to notify events to applications in order for application to know when they take place, and being able to control them optimally.

There wasn't a way to get this working meanwhile sticking to the v4l2 spec, therefore hacks were done by SoC drivers to overcome this.

Standard timings setting for video interfaces

There are video HW, like HDMI, that requires to negotiate timing settings between Transmitter and Receiver.

This is lacking on the v4l2 specification, and doing this negotiation is an actual need for many of this video interfaces.

Proposals

Media Controller

What is it?

It's a new Video4Linux device node that can be used to discover and modify the topology of the board and to give access to the low-level nodes (such as previewers, resizers, color space converters, etc.) that are part of the topology.

Why is needed?

• Discovering various device nodes created by a board.
• Being able to configure interconnections between subcomponents dynamically.
• Increasing demand to control sensors and/or video encoders/decoders more precisely.

Restrictions

• Shouldn’t affect existing applications.
• Don’t try to be too smart, just give full control to the application.
• Provide automatic default support for drivers that don’t create MC, for easing apps transition.
• All APIs specific to sub-devices _MUST_ be documented!
• Don’t abuse them to use direct register read/writes!

Concepts

• Entity: Subcomponent which could have multiple input and output pads. Has a unique ID per MC.
• Pad: Connecting point which could have several mutually exclusive links to other entities.
• Link: Connection between 2 pads.