Barcelona's Media Summit 2012 Report Notes
<P>During LinuxCon Europe/2012, there was the second Media Workshop in 2012. The
discusion notes are now available.</P>
<P>Presentations for the topics discused there are available
<a href="http://linuxtv.org/downloads/presentations/media_ws_2012_EU/">here</a>.</P>
<H1>1 Merging Process</H1>
<P>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.
</P>
<P>Mauro explained the
current merge process, and after that the floor was opened
for
discussions.
</P>
<P>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.
</P>
<P>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.</P>
<P>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.
</P>
<P>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).
</P>
<P>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.
</P>
<P>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?
</P>
<P>New drivers also must
come with a MAINTAINERS entry.
</P>
<P>In other words, the
MAINTAINERS file will become more important.
</P>
<P>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.</P>
<P>The submaintainers will
be:
</P>
<UL>
<LI><P>Mike Krufky:
frontends/tuners/demodulators
. In addition he'll be a reviewer for
DVB core patches.
</P>
<LI><P>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.
</P>
<LI><P>Laurent Pinchart:
sensor subdev drivers
</P>
<LI><P>Kamil Debski:
codec (aka memory-to-memory) drivers
</P>
<LI><P>Hans de Goede:
non-UVC USB webcam drivers
</P>
<LI><P>Guennadi
Liakhovetski: soc-camera drivers
</P>
</UL>
<P>In addition, certain
SoC vendors will remain responsible for their own drivers
(Samsung,
TI) and will keep sending them straight to Mauro.
</P>
<P>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.</P>
<H1>2 Requirements for New V4L2 Drivers</H1>
<P>The next topic was to
document the requirements for new drivers.
</P>
<P>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.
</P>
<P>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, ...).</P>
<P>For inclusion of pure
V4L2 drivers into the mainline kernel we require the following:
</P>
<UL>
<LI><P>Use struct
v4l2_device for bridge drivers, use struct v4l2_subdev for
sub-device drivers.
</P>
<LI><P>Use the control
framework for control handling.
</P>
<LI><P>Use struct v4l2_fh
if the driver supports events (implied by the use of
controls) or
priority handling.
</P>
<LI><P>Use videobuf2 for
buffer handling. Mike Krufky will look into extending
vb2 to
support DVB buffers.
</P>
<LI><P>Must pass the
v4l2-compliance tests.
</P>
</UL>
<P>The criteria for DVB
and hybrid V4L2 and DVB drivers should be discussed
further at the
ML</P>
<P>Those will be
documented likely in
Documentation/video4linux/SubmittingDrivers.txt.
</P>
<H1>3 V4L2 Ambiguities</H1>
<P>
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.
</P>
<P>- 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.
</P>
<P>- 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.
</P>
<P> 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.
</P>
<P>- 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.
</P>
<P>- 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.
</P>
<H1>4 Transport Stream Muxer</H1>
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<P>ST will make an RFC for
this idea to discuss this further on the mailinglist.
</P>
<H1>5 DMABUF Testing</H1>
<P>
Progress had been made
on this: Laurent showed UVC using DMABUF passing the buffer
directly to the i915
GPU.
</P>
<H1>6 Asynchronous Loading for Device Tree
</H1>
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<P>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.
</P>
<H1>7 Conclusion</H1>
<P>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!</P>
LinuxTV legacy CVS <linuxtv.org/cvs>