Hi Mauro, thanks for taking the time to look at this. >Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > >With Hans proposed changes that you've already acked, I think the proposal is >ok, >except for one detail: > >> 4. Format enumeration >> ---------------------------------- >> struct v4l2_fmtdesc, used for format enumeration, does include the >v4l2_buf_type >> enum as well, so the new types can be handled properly here as well. >> For drivers supporting both versions of the API, 1-plane formats should be >> returned for multiplanar buffer types as well, for consistency. In other >words, >> for multiplanar buffer types, the formats returned are a superset of those >> returned when enumerating with the old buffer types. >> > >We shouldn't mix types here. If the userspace is asking for multi-planar >types, >the driver should return just the multi-planar formats. > >If the userspace wants to know about both, it will just call for both types >of >formats. Yes. Although the idea here is that we wanted to be able to use single-planar formats with either the old API or the new multiplane API. In the new API, you could just set num_planes=1. So multiplanar API != multiplanar format. When you enum_fmt for mutliplanar types, you get "all formats you can use with the multiplanar API" and not "all formats that have num_planes > 1". This can simplify applications - they don't have to switch between APIs when switching between formats. They may even choose not to use the old API at all (if a driver allows it). Do we want to lose the ability to use multiplanar API for single-plane formats? Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- 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
