We use a frame-per-field update model because that's what DRM seems to want (to the extent that DRM bothers to specify such things...). One field gets displayed, the other discarded. If there is any scaling to be done, scaling happens first, on a full-frame basis.
The VC4 HVS has some register that you can poll that allegedly tell you if the last field was odd or even, which might help schedule frame updates? See viewtopic.php?p=2337562#p2335865
If you're desperate, there is another hack you can do (but it really is a hack): You could create a series of full frame-buffers, at field rate, where each buffer updates one field and repeats the opposite field. Provided there is absolutely no scaling (and no overscan margins) it should output each field 1:1. I mention this because it also works on Raspberry Pi 5. The drawback is that the latency is non-deterministic.
No standard software does this.
The VC4 HVS has some register that you can poll that allegedly tell you if the last field was odd or even, which might help schedule frame updates? See viewtopic.php?p=2337562#p2335865
If you're desperate, there is another hack you can do (but it really is a hack): You could create a series of full frame-buffers, at field rate, where each buffer updates one field and repeats the opposite field. Provided there is absolutely no scaling (and no overscan margins) it should output each field 1:1. I mention this because it also works on Raspberry Pi 5. The drawback is that the latency is non-deterministic.
No standard software does this.
Statistics: Posted by njh — Wed Jul 22, 2026 9:23 am
/fit-in/580x348/filters:format(webp)/english-betterindia/media/media_files/2026/08/04/1-2026-08-04-18-09-35.png)
/pic9729642.png)
