On 2/7/23 14:55, Kevin Brodsky wrote:
On 07/02/2023 13:22, Carsten Haitzler wrote:
struct drm_wait_vblank_reply32 {
It looks like this one needs some conversion too, as tval_{,u}sec are represented as long in native but currently s32 here.
how did i forget this? and not see it as a problem either... i literally have code that uses vblank events for animation timing that i wrote that i have actually tested against this that should have tripped over...
oh that's right! i just checked my git log. i disabled the code that used the device timestamp because that timestamp is not actually useful as it's the timestamp of the top-left pixel but the interrupt can fire BEFORE that pixel is scanned out and thus it's possible to get timestamps from the device that are in the future... which really messes everything up when time jumps forward then soon after in the next loop iteration if its picking up the next clock time from the system clock not the vblank clock it jumps back in time if the system is fast enough to do 2 loop iterations between vblank interrupt and the first pixel scanout time... gah... i forgot i changed that so it's not picking up the problem. got to love timeline warping issues that happen only in some cases that take a while to figure out. 😄
Right! I was wondering how that slipped through :) Would it be somehow possible to test that v3 works with DRM_IOCTL_WAIT_VBLANK? Just in terms of returning something in the right format, not from a functional perspective.
you mean v4? :) and yeah - it works. i tested. it produces sensible timestamps... animations are smood (and the timestamps are a nice 16.6667ms apart). so consider v4 working and tested for vblank timestamps too