What kmsdrm c/c++ function can I use to set VSync!?

[RedMarsBlueMoon]

Hello!

Short Version:
Does anyone know what c/c++ function I can use to correctly set/force the correct refresh rate in a program?

Long Version:
On RPi4b Bullseye 32bit, new flash + updated.

I'm converting a program to be able to run under both X11 and without, ie on the tty/CLI screens.
Its using Dear Imgui with SDL backend to draw a simple GUI. But this gui is vsync glitching up to the point at which I switch mode somewhat to a more pure kmsdrm render of a video stream.
When the program returns from the more direct kmsdrm render the vsync glitches on the GUI screen are completely gone!
This is repeatable and happens the same way every time.
Also when the program returns the frame rate of the GUI is locked to the expected 60fps, whereas previously it was rendering as fast as it could. (does not happen under X11)
You can see this happening here in this video. The glitching is best visible on the yellow field. Also check out the render time/fps in the upper edge.

https://www.youtube.com/watch?v=9p7AUBnokAk


I'm assuming that something in the code I'm using to initiate or draw sets a display mode more correctly than the Imgui-SDL manages to do. And that this new mode sticks and is being accepted by them and sorts out the refresh rate.
I'm thinking maybe the kmsdrm function drmModeAddFB2WithModifiers() or maybe drmModeSetPlane() is the one that does the magic fixing of the correct vsync. (source: https://github.com/Fredrum/chiaki/blob/ ... rime_out.c)
Is there anything I can run without image data? As the program is using a DRMPRIME format and I don't know how I could generate a spoof frame in that format. My idea was that otherwise I could just do a dummy run using the kmsdrm display function.

There are some other weird things about this problem.
When I remove the physical SD card and insert it in my PiZero2W (the above problem is with a 4b) and run the program exactly the same way the vsync glitching doesn't happen. This too is repeatable.
So it seems like the the display hardware of the two different Pi models behave differently using the exact same OS and code.

All this is on Bullseye 32bit, freshly flashed the other day and also doing update+upgrade.

On my other Buster SD cards this Vsync problem also does not appear.

Does anyone know what function I can use to enforce that correct display mode?
And does anyone know what's up with the strange Pi4b-vs-Zero2W difference?

Cheers!

[RedMarsBlueMoon]

I figured out what to do!
I could use some of SDL's display functions for listing and choosing display modes.
I believe these are called 'crtc's' in kmsdrm parlance? Not sure if they completely map from SDL to kmsdrm 1:1 but in my case it seemed to work to just set in SDL on app startup. And I have a monitor with the somewhat uncommon 1920x1200 res.

I was surprised to see that the X11 mode was RGB and the tty/CLI screen was ARGB.
I still don't understand why the Pi4b and the Zero2W behaved differently?

Cheers!

[cleverca22]

the difference might be which drm driver your using

"grep kms /boot/config.txt"

fkms is just a wrapper around the blob's dispmanx
while kms is directly driving the hw with linux drivers

[RedMarsBlueMoon]

I did double check that regular kms was used and not fake fkms and yep it was still at the Bullseye default 'kms'.
Another thing is the Zero2W has a different, 'mini', HDMI port which got me thinking that maybe it also has a different chip to do hdmi handshaking or edid supplying or something like that? Or maybe it's just a different VC chip I'll have to check if its using the VideoCore IV.

[6by9]

I did double check that regular kms was used and not fake fkms and yep it was still at the Bullseye default 'kms'.
Another thing is the Zero2W has a different, 'mini', HDMI port which got me thinking that maybe it also has a different chip to do hdmi handshaking or edid supplying or something like that? Or maybe it's just a different VC chip I'll have to check if its using the VideoCore IV.

Pi02 uses BCM2837, same as Pi3 (and more recent Pi2's).
The only external components on the HDMI interface are filters on the data pairs, and ESD protection on the I2C and CEC lines.

[RedMarsBlueMoon]

It's all good as it's working on both Pi models now.
I think it was bad code anyway to leave the video mode 'undefined' in the tty/cli environment. But the example code I have been looking at didn't have any explicit mode setting so I never thought about that. They were probably designed for X11 though.