On 06/07/17 04:45 PM, Michel Dänzer wrote:
On 06/07/17 07:10 AM, Keith Packard wrote:
This modifies the datatypes used by the vblank code to provide both 64 bits of vblank count and to increase the resolution of the vblank timestamp from microseconds to nanoseconds.
The driver interfaces have also been changed to return 64-bits of vblank count; fortunately all of the code necessary to widen that value was already included to handle devices returning fewer than 32-bits.
This will provide the necessary datatypes for the Vulkan API.
Signed-off-by: Keith Packard keithp@keithp.com
[...]
@@ -1492,9 +1515,11 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
switch (vblwait->request.type & _DRM_VBLANK_TYPES_MASK) { case _DRM_VBLANK_RELATIVE:
vblwait->request.sequence += seq;
vblwait->request.type &= ~_DRM_VBLANK_RELATIVE;req_seq = seq + vblwait->request.sequence;
Subtle breakage here: vblwait->request.sequence must still get updated for _DRM_VBLANK_RELATIVE, in case we're interrupted by a signal.
BTW, this got me thinking that we should probably treat _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating vblwait->request.sequence. Otherwise there could theoretically (though unlikely) be an infinite loop:
ioctl with _DRM_VBLANK_NEXTONMISS, target missed => wait for next vblank wait interrupted by signal lather, rinse, repeat
I'd advise against adding a "next on miss" flag for the new ioctl until there is specific demand for that.