Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Hans Verkuil <hverkuil <at> xs4all.nl>
Subject: Barcelona Media Summit Report
Newsgroups: gmane.linux.drivers.video-input-infrastructure
Date: Friday 16th November 2012 12:58:54 UTC (over 3 years ago)
Hi all,

This is the report of the Barcelona Media Summit on November 8. For those
who
were in attendence: please correct any mistakes I may have made.

My presentation for the 'Minimum Requirements for New Drivers' and the
'V4L2
Ambiguities' can be found here:

http://hverkuil.home.xs4all.nl/presentations/ambiguities2.odp

I'd appreciate it if other presentations shown during the meeting can be
made
available as well.

Enjoy!

	Hans

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
look into extending patchwork to have such patches be marked as 'Under
Review'
automatically.

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, where that doesn't make sense). When posting
review
patches the reviewed-by/acked-by from the actual person mentioned in the
MAINTAINERS file is sufficient to get the patch merged. 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.

The submaintainers will be:

- Mike Krufky: frontends/tuners/demodulators
	In addition he'll be the 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 the 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. Only
when that is done do the new submaintainers start their work.


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 at the time of submission.
That is all it should take to be accepted into staging.

For inclusion 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.

This will be documented as well in
Documentation/video4linux/SubmittingDrivers.txt.


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
  I wrote for this was accepted, with the addition that the code to handle
  tuner ownership should be shared between DVB and V4L2. I have my name
  and Hans de Goede's name next to this topic, but I've forgotten what we
  were supposed to do :-)


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.


DMABUF Testing
==============

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


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.


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!

Regards,

	Hans Verkuil
 
CD: 3ms