<!-- 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>

   ndufresne: hverkuil, svarbanov pointed me to the spec of something else today, that was saying the regardless if you are doing mplane or not, the non-plane type should be use
   <br> This decision creates a huge mess userspace whise, so before I start creating that mess in GStreamer, I'd like to know if this is really intentional
   <br> in vivid, S/G_PARM, will adapt, while G/S_SELECTION and CROPCAP will not
   <br> I have no idea what could rationally differentiate g/s_parm from the others
   <br> same inconcistency with v4l_g_crop emulation, it checks with  V4L2_TYPE_IS_OUTPUT(), which is both, and then call into g_selection, which is speced as only non-mplane type
   <br> hverkuil, another note, maybe we should document that v4l2_plane_pix_format.sizeimage and v4l2_plane.length also includes v4l2_plane.data_offset ?
   <br> hmm, and in vivid, data_offset is not set when doing the initial QUERYBUF, that one looks like a bug
   <br> (or at least it would be for an OUTPUT device, need to check the output)
   ***: koike has quit IRC (Ping timeout: 264 seconds)
   svarbanov: <u>ndufresne</u>: I think it is intentional because v4l2-compliance complains about MPLANE buffer types. See https://git.linuxtv.org/v4l-utils.git/tree/utils/v4l2-compliance/v4l2-test-formats.cpp#n1287
   ***: narmstrong has quit IRC (Remote host closed the connection)
   kbingham: <u>sailus</u>: I've just been looking at your fwnode series.
   <br> <u>sailus</u>: I was thinking that I would make the async all match on the nodes for the endpoints that perform links, rather than the device nodes. At a first thought - how does this affect the fwnode work?
   hverkuil: <u>ndufresne</u>: that's correct, for s/g_selection and the cropping ioctls you use the non-MPLANE buffer type. I don't really remember why we did that.
   <br> I would be inclined to just allow both in the selection/crop ioctls. I think the rationale was originally that selection is unrelated to single/multi plane. But so is g/s_parm, and we never did the same there.
   <br> <u>ndufresne</u>: it is right that data_offset isn't set in the initial querybuf: this information is only set after the buffer is queued (or really, after a buffer is captured, but vivid sets it in the prepare() callback).
   <br> In theory the data_offset could be different for each frame captured.
   pinchartl: <u>hverkuil</u>: data_offset is still a big mess. I've posted a patch a while ago to get that fixed but it never got accepted
   hverkuil: <u>pinchartl</u>: can you point me to that patch? I faintly remember it, but not the details.
   pinchartl: <u>hverkuil</u>: https://patchwork.kernel.org/patch/6217571/ and http://www.spinics.net/lists/linux-media/msg88652.html
   <br> I mean
   <br> <u>hverkuil</u>: https://patchwork.kernel.org/patch/6217571/ and https://patchwork.linuxtv.org/patch/29178/
   <br> "[PATCH/RFC 0/2] Repurpose the v4l2_plane data_offset field" on the mailing list
   <br> that was two years ago
   <br> I assume the situation has deteriorated since then
   <br> it certainly hasn't improved
   hverkuil: Situation is unchanged. Nor am I particularly willing to make changes here. What I *do* want to do is to make a new set of streaming ioctls with a new and much improved struct v4l2_buffer. We need to due to year 2038 issues with the current timestamping.
   <br> This is also an opportunity to simplify multi/singleplane handling (currently very hard on userspace). And this whole data_offset mess can be cleaned up at the same time.
   <br> We should never have added data_offset  at that time :-(
   pinchartl: <u>hverkuil</u>: we clearly shouldn't have added it, I agree
   <br> there are many things we would do differently. regrets won't improve anything unfortunately
   <br> I'm increasingly of the opinion that the best qualifier for V4L2 today is bloated
   ndufresne: hverkuil, ok, the point of driver type is that you should not have to care about it while using the API, you pick a mode, then there is one type, while with g_selection, userspace need special case, I'd be curious to find out why it was done like this
   <br> but could not blame due to doc being rewriten to .rst
   <br> hverkuil, ok, I didn't know/expected that the data_offset would vary per plane, it's a bit strange, not sure that feature will be used much
   hverkuil: <u>ndufresne</u>: I can't remember why we did it like that (buffer type). It was an unfortunate choice.
   ndufresne: hverkuil, so it's an old decision
   <br> so CROPCAP and G/S_SELECTION have this exception, I'll try and find the full list
   hverkuil: <u>ndufresne</u>: yes. And yes, it's only crop(cap), g/s_selection that have this. I don't care about the old cropping ioctls (don't use them :-) ), but this is annoying for the selection ioctls.
   <br> I think this restriction should be lifted.
   ndufresne: lifting it is still backward compatible
   hverkuil: <u>interesting</u>: the exynos drivers expect the _MPLANE buf type. Hmm.
   ndufresne: to be faire, none of the driver I've been using G_SELECTION on (decoders, to read the display region) checks for the type
   <br> ah, oops, missed that one then ;-P
   <br> arg, that's annoying
   hverkuil: Yeah. It is.
   <br> I wasn't aware of the exynos drivers doing this.
   <br> I think I have to fix this mess.
   svarbanov: <u>hverkuil</u>: you should fix v4l2-compliance too ;)
   hverkuil: <u>ndufresne</u>: made a quick patch for this: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=selfix
   <br> Just compile-tested, though.
   ndufresne: hverkuil, that enables all usage, I think it's a good solution, and should not break anything
   <br> the if/else if is exactly what I added yesterday locally in gst to test further
   ***: benjiG has left