From: "Yu, Jinlu" <jinlu.yu@intel.com>
To: "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: RE: V4L-DVB Summit Day 1
Date: Thu, 24 Sep 2009 19:52:44 +0800 [thread overview]
Message-ID: <037F493892196B458CD3E193E8EBAD4F01ED6EEE13@pdsmsx502.ccr.corp.intel.com> (raw)
In-Reply-To: <200909232239.20105.hverkuil@xs4all.nl>
About S_FMT, Moorestown Camera driver which I am working on has a different story.
We do use different sensor resolutions, because high resolution has low FPS, and can not be used for view-finding, e.g. ov5630 only output 15fps with 5Mega resolution.
Our current solution is to disable the scaler in ISP and only support the resolutions that sensor can provide. So S_FMT will set the framesize into sensor.
Best Regards
Jinlu Yu
UMG UPSG PRC
INET: 8758 1603
TEL: 86 10 8217 1603
FAX: 86 10 8286 1400
-----Original Message-----
From: linux-media-owner@vger.kernel.org [mailto:linux-media-owner@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: 2009年9月24日 13:39
To: linux-media@vger.kernel.org
Subject: V4L-DVB Summit Day 1
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-09-24 11:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-24 5:39 V4L-DVB Summit Day 1 Hans Verkuil
2009-09-24 11:52 ` Yu, Jinlu [this message]
2009-09-24 18:07 ` Guennadi Liakhovetski
2009-09-26 8:40 ` Dongsoo, Nathaniel Kim
2009-09-26 9:32 ` Guennadi Liakhovetski
2009-09-26 13:06 ` Dongsoo, Nathaniel Kim
2009-09-26 19:31 ` Hans Verkuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=037F493892196B458CD3E193E8EBAD4F01ED6EEE13@pdsmsx502.ccr.corp.intel.com \
--to=jinlu.yu@intel.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.