Hi all,
As most of you know I organized a v4l-dvb summit (well, really a v4l2 summit
as there were no dvb topics to discuss) during the Linux Plumbers Conference
in Portland. This summit will take all three days of this conference, and I
intend to make a short report at the end of each day.
First of all I want to thank everyone who attended this first day of the
summit: we had a great turn-out with seven core v4l-dvb developers, three TI
engineers, two Nokia engineers, two engineers from Samsung and an Intel
engineer. I know I've forgotten someone, I'll try to fix that tomorrow.
But it meant that the main SoC vendors with complex video hardware were well
represented.
The summit started off with an overview of the proposed media controller and
an overview of the features of several SoCs to give an idea of what sort of
complexity has to be supported in the future. I'll try to get some of the
presentations up on my site. Unfortunately, not all presentations can be made
public. The main message that came across though is that these complex devices
with big pipelines, scalers, composers, colorspace converters, etc. require a
completely new way of working.
While we did discuss the concepts of the media controller, we did not go into
much detail: that is scheduled for Thursday.
In the afternoon we discussed the proposed timings API. There was no
opposition to this API. The idea I had to also use this for sensor setup
turned out to be based on a misconception on how the S_FMT relates to sensors.
ENUM_FRAMESIZES basically gives you the possible resolutions that the scaler
hidden inside the bridge can scale the native sensor resolution. It does not
enumerate the various native sensor resolutions, since there is only one. So
S_FMT really sets up the scaler.
So we can proceed with the timings RFC and hopefully have this implemented for
2.6.33.
Next was the event API proposal: this caused some more discussions, in
particular since the original RFC had no provision for (un)subscribing to
events. The idea is that we want to subscribe to events on a per-filehandle
basis. The core framework can keep track of events and distribute them to
filehandles that 'listen' to them. So this RFC will clearly need to go to at
least one revision.
That was also a good point to stop for the day and head out to get free beer
and food :-)
Scheduled for Thursday is a discussion of the proposed memory pool and
continued media controller discussions.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
