summaryrefslogtreecommitdiff
path: root/test/serialization/generated_serializer/include
diff options
context:
space:
mode:
authorPaul Elder <paul.elder@ideasonboard.com>2021-03-30 18:43:38 +0900
committerPaul Elder <paul.elder@ideasonboard.com>2021-05-25 18:20:55 +0900
commit77c6ac0ae70e962a3776a06fa844653f181183cc (patch)
treeb20c7ee04c90ea4ca076a5b4b647daac6c878059 /test/serialization/generated_serializer/include
parent63c3c545926d7eb9af8c03930e79df8c2b46a8e9 (diff)
android: CameraDevice: Report proper min and max frame durations
The HAL layer was getting the min and max frame durations from the camera, then rounding it to fps to report as available fps ranges. The same min and max frame durations were then being reported as min and max frame durations. Since the fps are integer values while the frame durations are in ns, this caused a rounding error making it seem like we were reporting an available max fps that was higher than what was allowed by the minimum frame duration. An example is if the minimum frame duration is reported as 33366700ns. The HAL layer would then convert it to fps, which is 29.97, but it would be rounded and reported as 30 fps. When 30 fps is converted to a frame duration it is 33333333ns, which is less than the minimum frame duration that we report. Thus the minimum frame duration that we report contradicts the fps range that we report. Fix this by recalculating the frame durations based on the rounded fps values. This allows the following CTS test to pass: - android.hardware.camera2.cts.SurfaceViewPreviewTest#testPreviewFpsRange Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Diffstat (limited to 'test/serialization/generated_serializer/include')
0 files changed, 0 insertions, 0 deletions