Em 28-08-2012 21:15, Hans Verkuil escreveu:
Hi all,
Here are the links to my presentations and below that the raw text of the etherpad.
A more polished version will be posted to the mailinglist eventually, but that's probably going to be Monday at the earliest. Unless someone else wants to do this?
I'm reviewing the etherpad stuff, hoping to be able to release it today.
Yet, with regards to this item:
V4L2_CAP_VIDEO_CAPTURE If a driver supports only formats with more than one plane, should V4L2_CAP_VIDEO_CAPTURE still be defined? And if a driver also supports single-plane formats in addition to >1 plane formats, should V4L2_CAP_VIDEO_CAPTURE be compulsary? The consensus seems to be 'No' and 'No'. The CAPs refer to whether the single and/or multiplanar API is implemented, not whether single and/or multiplanar formats are available.
The etherpad note said "No and No", but I think it should be saying, instead: "Flags should reflect what it is visible/usable by the userspace API."
I remember that, when those patches got merged, there was a discussion about having a kernel code that simulates a monoplane API. As it was a looong time ago, I'm not 100% sure anymore what happened with that code, but I think it ended by being merged at v4l-utils.
If so, that means that the s5p drivers should not return V4L2_CAP_VIDEO_CAPTURE flags, but the v4l-utils library should return it, due to the emulation logic there.
In other words, fixing the driver to do the right thing also means that the library should be patched to properly report that library clients can use both MPLANE an monoplane variations.
Regards, Mauro