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@xxxxxxxxxxxxxxx [mailto:linux-media-owner@xxxxxxxxxxxxxxx] On Behalf Of Hans Verkuil Sent: 2009年9月24日 13:39 To: linux-media@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html ?韬{.n?????%??檩??w?{.n???{炳g???^n?■???h?璀?｛?夸z罐?+€?zf＂?????i?????_璁?:+v??撸?
