During LinuxCon Europe/2012, there was the second Media Workshop in 2012. The discusion notes are now available.

Presentations for the topics discused there are available here.

1 Merging Process

The morning was spent discussing the merging process. Basically the number of patch submissions increased from 200 a month two years ago to 700 a month this year. Mauro is unable to keep up with that flood and a solution needed to be found.

Mauro explained the current merge process, and after that the floor was opened for discussions.

One of the problems is that it can be difficult to categorize patches since often they are just prefixed with [PATCH]. Depending on who mailed it that might mean an urgent regression fix, a patch that's ready to be merged or a patch that needs review. There is no reliable way of knowing that without actually looking at the mail.

One thing that we want to improve is to make sure that the regular contributors at least use well defined patch prefixes. That means that we need a standard prefix for regression fixes that need to go into the current rcX kernel asap. This will make it easy to recognize them. We also need a prefix for patches that we want to have reviewed before a final git pull request is posted. Laurent will work into extending patchwork to delegate patches to sub-maintainers when they arrive there.

There is a distinction between RFC patches and patches you consider final (i.e. ready for merging), but want people to look at. RFC patches will typically need more work, but you want people to check it out and make sure you are going in the right direction. Review patches are what you consider the final version, but you want to give people a final chance to comment on them before posting the pull request.

We also want to improve the MAINTAINERS file: it must be complete (with the exception of RC keymaps and RC/V4L2/DVB core, where that doesn't make sense).

A patch reviewed-by/acked-by from the actual person mentioned in the MAINTAINERS file and that follows the submission rules can be considered with enough review for its merge. Obviously, if someone not responsible for the driver in question has good technical arguments why it's wrong, then that should be taken into account.

In addition, the current list of media driver maintainers in that file needs to be validated: are all emails still current, and is everyone still willing to maintain their driver?

New drivers also must come with a MAINTAINERS entry.

In other words, the MAINTAINERS file will become more important.

The final decision we made was to appoint submaintainers of parts of the media subsystem. Those submaintainers will take over Mauro's job for those parts that they are responsible for, and make periodic pull requests to Mauro to pull in the patches they have collected. Mauro will still be doing a second review on such patches.

The submaintainers will be:

• Mike Krufky: frontends/tuners/demodulators . In addition he'll be a reviewer for DVB core patches.

• Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video receivers and transmitters). In addition he'll be a reviewer for V4L2 core patches.

• Laurent Pinchart: sensor subdev drivers

• Kamil Debski: codec (aka memory-to-memory) drivers

• Hans de Goede: non-UVC USB webcam drivers

• Guennadi Liakhovetski: soc-camera drivers

In addition, certain SoC vendors will remain responsible for their own drivers (Samsung, TI) and will keep sending them straight to Mauro.

The first step is to get the MAINTAINERS file into shape and to improve patchwork, after that we need to clearly document the new structure.

2 Requirements for New V4L2 Drivers

The next topic was to document the requirements for new drivers.

For the staging tree we want drivers to compile cleanly at the time of submission. Typically, that is all it should take to be accepted into staging.

It should be noticed though that a driver submitted for staging is a driver that are meant to be promoted one day as a main driver, and someone will actively work on them. So, drivers that can't be promoted to a main driver won't be merged at staging (e. g. drivers for already supported hardware, utterly bogus drivers, ...).

For inclusion of pure V4L2 drivers into the mainline kernel we require the following:

• Use struct v4l2_device for bridge drivers, use struct v4l2_subdev for sub-device drivers.

• Use the control framework for control handling.

• Use struct v4l2_fh if the driver supports events (implied by the use of controls) or priority handling.

• Use videobuf2 for buffer handling. Mike Krufky will look into extending vb2 to support DVB buffers.

• Must pass the v4l2-compliance tests.

The criteria for DVB and hybrid V4L2 and DVB drivers should be discussed further at the ML

Those will be documented likely in Documentation/video4linux/SubmittingDrivers.txt.

3 V4L2 Ambiguities

In San Diego we discussed a lot of V4L2 ambiguities and how to resolve them, but we didn't have time to go through all of them. We finished it in Barcelona.

- What to do if the colorspace is unknown? This happens with UVC webcams that do not report this. The decision was to make a V4L2_COLORSPACE_UNKNOWN. If that is reported, then no colorspace conversion should be attempted by the application.

- Pixel Aspect Ratio: currently this is only available from VIDIOC_CROPCAP, which conflicts with the new selection API, and it doesn't really belong there anyway.

The decision was to implement the pixel aspect ratio as a control, which implies adding a control type for fractions. This needs good documentation and a code example.

- Should we add a QUERYCAP ioctl for subdevice nodes? The conclusion was that we should add a VIDIOC_SUBDEV_QUERYCAP ioctl. Initially that just needs a version field and some reserved fields and it can be handled in v4l2-subdev.c.

- Tuner ownership: how should the tuner ownership be handled? The proposal that Hans Verkuil wrote for this was accepted, with the addition that the code to handle tuner ownership should be shared between DVB and V4L2. Hans de Goede, with the help of Hans Verkuil, will be working on an RFC code to handle tuner ownership for radio and video.

4 Transport Stream Muxer

ST discussed how to design a driver for a hardware Transport Stream Muxer: this hardware contains a number of DMA engines allowing many transport streams (up to 8192, which is the theoretical maximum) to be muxed into a single big transport stream.

Due to the large number of possible transport streams one cannot make a video node for each of them. So the solution is to have one memory-to-memory device.

Every time it is opened you make a new context (filehandle specific) and after setting up the PID (and possibly other (meta) data) you can write the TS to it. There is only one output stream, though. Perhaps we need a new /dev/tsmuxX device node for this, that's still to be decided.

ST will make an RFC for this idea to discuss this further on the mailinglist.

5 DMABUF Testing

Progress had been made on this: Laurent showed UVC using DMABUF passing the buffer directly to the i915 GPU.

6 Asynchronous Loading for Device Tree

The device tree patches posted by Guennadi were well received, but the part dealing with async loading of devices led to a lot of discussion on the mailinglist so we tried to come to a conclusion during the summit meeting.

The current patch uses a field in the platform_data of a subdevice to detect whether the bridge driver was present. A better solution is to check for the presence of required resources (e.g. a clock) instead: if not present, then defer probing.

It was noted that the asynchronous behavior of the device tree will lead to subdevices that are loaded in a random order. This might cause subtle problems in the future if the order of device initialization matters for certain boards.

It shouldn't matter, but theory and reality are different things. There is nothing that can be done about it at the moment. Should this become a problem, then that should be discussed with the DT developers since this is a DT problem and is not specific to V4L2.

The 'group' idea in the async loading patches wasn't liked. Instead the suggestion was to provide two different notification methods: a notification when the last required subdev is loaded, and a notification for each loaded subdev. The latter can be used when not all subdevs might be present. In that case the bridge driver needs to be able to decide when sufficient subdevs were found in order to start up.

7 Conclusion

We managed to get through all topics during this one-day summit, so it was very productive. I'd like to thank all who were there, it's always a pleasure to meet you all!

mchehab