<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   hverkuil: <u>sailus</u>: hi!
   sailus: <u>hverkuil</u>: A quick question on VIDEO_CAPTURE and VIDEO_CAPTURE_MPLANE types.
   <br> The multi plane API covers basically what the single plane variant does, but do we have guidelines for which one to pick for new drivers?
   <br> It would seem that there isn't much missing from allowing drivers to support both without changes but it doesn't seem to be supported right now.
   <br> Say, if the hardware only supports formats that don't need multi-plane API, should it use single plane API?
   hverkuil: sorry, got distracted.
   <br> Yes, if it only supports single planes then use the single plane API. It is better supported than the multi-plane API.
   <br> If the HW *can* support multiplanar formats, but the driver doesn't support them (yet), then it is a gray area and it is in practice up to the driver developer.
   <br> I've got some patches here: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=v4l2-buffer that add extended stream ioctls (using a v4l2_ext_buffer) that would make it much easier to be multi/single planar agnostic in userspace.
   <br> I think we made a major mistake at the time trying to shoehorn multiplanar support into v4l2_buffer. It's way too complex for userspace to deal with this.
   <br> Live and learn...
   sailus: Ack.
   <br> Makes sense. We'll need to replace v4l2_buffer at some point, perhaps it'd been too early when the MPLANE formats were introduced.
   <br> Anyway, we can do it soon then. :-)
   <br> <u>hverkuil</u>: I replied to the thread on tc&lt;alotofnumbershere&gt;.
   <br> I think g_mbus_config is usable here, it's a rare use case that there are fewer lanes in use than routed.
   ***: prabhakarlad has left
   <br> benjiG has left