[PATCH v4l-utils v2 0/2] fix expected buffer length calculation

[Sarah Gershuni <sarah556726@gmail.com>]

v2:

In this updated version:

- Restore single-buffer calculation using bytesperline
  Replace the multi-planar v4l2_fwht_find_pixfmt-based logic with the
  original single-buffer model, using bytesperline instead of assuming
  stride == width.

- Keep plane_bytesperline as added in v1
  The plane_bytesperline array and its initialization in
  g_fmt_setup_trace are unchanged from v1.


- Link to v1: https://lore.kernel.org/all/20260316132223.7337-1-sarah556726@gmail.com/

v1:
The current implementation assumes that stride equals image width,
which leads to incorrect buffer size calculations when padding is present.

This series fixes the issue by introducing stride-aware handling.

The previous version computed buffer sizes using per-plane
bytesperline values and v4l2_fwht_find_pixfmt, iterating over all planes.

Patch 1 introduces plane_bytesperline to store per-plane stride.
Patch 2 uses it to compute the expected buffer length.


Thanks,
Sarah

Signed-off-by: Sarah Gershuni <sarah556726@gmail.com>
---
Sarah Gershuni (2):
  add plane_bytesperline to trace_context
  use bytesperline for expected buffer length calculation

 utils/v4l2-tracer/trace-helper.cpp | 22 ++++++++++++++--------
 utils/v4l2-tracer/trace.h          |  1 +
 2 files changed, 15 insertions(+), 8 deletions(-)

-- 
2.43.0