Just the software. Which, to be honest, makes all this more confusing
Didn't try that.
I wrote debug output indicating the state of each screen including a sequentially incremented frame number, whether it's drmModePageFlip'ed already and when the callback confirming a flip arrived. Essentially each frame when through 3 states: next (ready and waiting to be flipped), flipping (waiting for vsync confirmation) and current (it's now on the screen). The debug output printed that to the console IIRC 1000 times per second and you could see a pattern where the frame becoming current on one screen happened at roughly half way between a complete cycle on the other screen. As 60Hz is 16.6ms/frame, the offset was around 8ms.And how can you measure the delay?
I did not do any long term tests to see if there's any drift.
No need to make this a prerequisite or wait: If you want to test the software and see if the syncing works for your use case, you can use the "private" version for free. It's feature-identical to the paid version, except you can not use if for any public or commercial use cases.
Sorry, I seem to have missed the topic notifications. The debug view isn't included in the default build of info-beamer and even then its output is quite confusing and not very actionable. As long as there's no proper way to force synchronization, I fear the randomness is all that's possible at the moment.