Anybody know how DRM_IOCTL_WAIT_VBLANK works on PI4/Bookworm with respect to the returned vblank_time_value? Capture the monotonic time via clock_gettime(CLOCK_MONOTONIC, ...) immediately after the ioctl returns (with _DRM_VBLANK_RELATIVE and sequence > 0 so it blocks) and the returned vblank_time_value (reply.tval_sec*1000000 + reply.tval_usec) is in the future relative to when the ioctl returned.
My best guess is a blocking call returns at vsync_start time and the returned vblank_time_value is the next frame_start? At 60hz, the mode values are: vdisplay=1080, vsync_start=1084, vsync_end=1089 and vtotal=1125. Calculating vblank_time_value minus clock_gettime(monotonic) = ~625usec so the math seems reasonable.
Had assumed that the ioctl return time and the vblank_time_value would effectively be the same (with the driver choosing some reference point), so this was unexpected behavior. No problem if this is the intended behavior, but curious if other devices, platforms, etc. do the same. Appreciate any details to fill in the gaps. Thanks.
My best guess is a blocking call returns at vsync_start time and the returned vblank_time_value is the next frame_start? At 60hz, the mode values are: vdisplay=1080, vsync_start=1084, vsync_end=1089 and vtotal=1125. Calculating vblank_time_value minus clock_gettime(monotonic) = ~625usec so the math seems reasonable.
Had assumed that the ioctl return time and the vblank_time_value would effectively be the same (with the driver choosing some reference point), so this was unexpected behavior. No problem if this is the intended behavior, but curious if other devices, platforms, etc. do the same. Appreciate any details to fill in the gaps. Thanks.
Statistics: Posted by Vraz — Thu Sep 12, 2024 9:05 pm