<div dir="ltr">Hi pekka<div><br></div><div>I debug the presentation time recently. I have checked each user call drmAtomicCommit get the corresponding pageflip event.</div><div>But some presentation results (c2p) are a little weird. They are 1~5ms or -1 ~ -5 ms. some results are normal(8 ~ 20 ms).</div><div>I used to explain the weird result is because  pageflip return last frame's timestamp, but I can't explain the normal results.</div><div><br></div><div>I suspect whether the kernel and user have the same time start point. It's just a guess, I have no evidence.</div><div><br></div><div>Do you have some tips about the c2p results? Thank you.</div><div><br></div><div>Best Regards</div><div>Nancy</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-12 23:17 GMT+08:00 Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 10 May 2018 12:53:49 +0800<br>
<span class="">zou lan <<a href="mailto:nancy.lan.zou@gmail.com">nancy.lan.zou@gmail.com</a>> wrote:<br>
<br>
> Hi pekka<br>
> <br>
</span><span class="">> I test presentation on my side. The presentation results is not accurate<br>
> because our pageflip event send last frame's timestamp every time. So<br>
> weston_output_finish_frame send last frame's present tine<br>
> to current frame's feedback. For this situation, I just delay one frame to<br>
> send present event. Does this get the right c2p time? Thank you.<br>
<br>
</span>Hi Nancy,<br>
<br>
I think your driver needs to get fixed, so that it provides the<br>
correct timestamp instead of an outdated one. If this is a kernel<br>
DRM driver, then the behaviour you describe is clearly a bug. The<br>
timestamp of the pageflip event signifies the time the new frame<br>
starts transmitting out of the connector. I believe there should be<br>
DRM driver API documentation stating that.<br>
<br>
This is also what weston_output_finish_frame() expects. Anything<br>
else will cause the frame scheduling to misbehave.<br>
<br>
It may be possible to work around the bug as you suggest, but that<br>
will make the compositor incorrect on any other driver, and it may<br>
cause other subtle breakage (the timestamp may be correct, but the<br>
time the event gets sent is now wrong and might even be delayed<br>
indefinitely if nothing causes a repaint).<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div>