libv4l-rockchip_v2: Match ioctl_s_selection*() with ioctl_g_crop*()
On kernel 4.4, we only supported VIDIO_{G,S}_CROP, and we made some
small compatibility adjustments in this plugin. On 5.10+, we support
VIDIO_S_SELECTION, which is a superset of the CROP API. Note that the
"setter" (for VIDIOC_S_SELECTION) is actually a bidirectional API, which
returns (overwrites) some values in the argument based on codec
behavior.
When implementing the SELECTION shim in this plugin, we didn't quite
imitate the ioctl_{g,s}_crop_locked() support correctly; for crop, we
were returning the (2-aligned) input width/height, not the
potentially-different values returned by the kernel. But for
ioctl_s_selection_locked(), we return the kernel values. This causes an
issue, because the underlying Rockchip/Hantro encoder rounds widths up
to a 4-pixel alignment, and upper layers (Chrome/ARC) aren't expecting
that.
Imitate the ioctl_g_crop*() implementation, for compatibility.
It's not clear to me that this is the most purely correct
implementation, as it seems like the VIDIOC_G_CROP and
VIDIOC_S_SELECTION docs clearly describe how underlying hardware may
make alignment decisions that aren't precisely what were requested. But
it seems wise to be consistent for now, at least, even if there are more
improvements to be made in our users (e.g., Chrome).
BUG=b:230996595
TEST=CtsMediaTestCases on kevin kernel 5.10
Change-Id: Ibf05df3339a134a0cb48ce2a72fcbc1f6558a3da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/libv4lplugins/+/3631469
Reviewed-by: Hirokazu Honda <[email protected]>
Tested-by: Brian Norris <[email protected]>
Reviewed-by: Chih-Yu Huang <[email protected]>
Commit-Queue: Brian Norris <[email protected]>
Reviewed-by: Steve Cho <[email protected]>
1 file changed
