dividuum wrote: ↑
Mon Sep 16, 2019 12:32 pm
piense wrote: ↑
Mon Sep 16, 2019 4:26 am
Well I got most things working. Only issue seems to be that if I update multiple planes in one atomic commit it takes longer than it should, ie 2 frames (well vblanks) instead of one.
I would be interested if you find a solution for that. I haven't tried using the atomic API yet, but with the legacy drmModePageFlip API, I also run into issues syncing two displays: The drmModePageFlip doesn't always return immediately and instead seems to wait for up to 16ms for one of the displays. I tried to solve this with a threaded approach, but i'm not happy with that. If you closely monitor the vsync timestamps of both displays, I also notice that they are more or less randomly shifted by up to 8ms. If you're lucky, they flip at the same time. If you're unlucky, they are up to 8ms apart and I've not yet figured out how to handle/predict this.
Found this comment which may be what's happening in your case:
drm_atomic.c line 1663:
* This way explicit fencing can be used to overrule implicit fencing, which is
* important to make explicit fencing use-cases work: One example is using one
* buffer for 2 screens with different refresh rates. Implicit fencing will
* clamp rendering to the refresh rate of the slower screen, whereas explicit
* fence allows 2 independent render and display loops on a single buffer. If a
* driver allows obeys both implicit and explicit fences for plane updates, then
* it will break all the benefits of explicit fencing.
I could be wrong, still figuring all this out. I have some guesses on my problem, but I'm not quite convinced I understand enough of the code to be sure.