I am working on a Qt5 based application that utilizes two displays connected via HDMI on a Raspberry Pi 4. I am encountering a issue that I think is similar to the below post.
viewtopic.php?p=1511966&hilit=drmModePageFlip#p1511966

Basically, if drmModePageFlip is called on multiple displays, they seem to interfere with each other resulting in long delays (30+ ms) and missed vsyncs, which causes jittery animation. The delay can be avoided via passing the ASYNC flag to one of the drmModePageFlip calls, but that interferes with the animation timing, which is reliant on waiting for vsync.

The current environment:
Yocto Kirkstone
Kernel: 5.15.92
Firmware: 20220830

If anyone knows if there were any bugs fixed in the kernel and/or firmware that may address this, or any other general advice on the usage on the DRM api in this regard, your input is appreciated.

5.15 is obsolete having been last updated over 2 years ago.

Using DRM_MODE_PAGE_FLIP_ASYNC is unlikely to be what you want - it immediately updates the plane properties, which can result in tearing. (There are some restrictions on which properties can change with an ASYNC flip).

Using DRM_MODE_PAGE_FLIP_EVENT should trigger a page flip event. I seem to recall a recent thread where the main DRM devs acknowledged that vsync and flip events miss out saying which crtc they belong to.

More common these days is to use the atomic API to commit changes atomically. I'd need to double check with a colleague, but I believe that as long as the commits contain no state in common, then you can have 2 atomic commits running in parallel. (If any resources are shared, then you're likely to get an EBUSY when submitting the second one as it does not allow queuing multiple commits).

Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Using DRM_MODE_PAGE_FLIP_EVENT should trigger a page flip event. I seem to recall a recent thread where the main DRM devs acknowledged that vsync and flip events miss out saying which crtc they belong to.

I don't think I've used the combination of drmModePageFlip and page_flip_handler2 in any of my various implementation I've written over the years, but maybe using version 4 of the drmHandleEvent fills in the crtc_id? At least it did for me when I was using it together with drmModeAtomicCommit. One more reason maybe to use those:

Unless the intent is to drive two displays with different refresh rates, It might be easier to do one atomic commit across all resources. At least that's what I've been doing for a while now and I don't notice any downsides so far. Although I'm using fences instead of drmHandleEvent now. Whether or not that all works well on such an old kernel is the question though.

info-beamer hosted - A user and programmer friendly digital signage platform for the Pi: https://info-beamer.com/hosted