18:26 <sawyer> flokli: I have a feeling they added some hardware acceleration for doing brightness compensation for the VRR oled panels, since if you pulse an image less often you need to maintain the same power/duty cycle ratio--seems like they may have "proper" VRR support on those panels instead of the "you have 5 display modes the panel can switch between with predefined timings" that phones have had for a while

11:40 <leio> hmm, I should later try 1080p and actually making sure the monitors own settings have VRR allowed

11:38 <leio> though I guess it might be a bit of a problem to use for me, as the monitors I have that do 30-60 VRR are capped to 30Hz with the firmware. The other day macOS decided to also max out driving it over HDMI in 1920x1080@50Hz and not let me go 4K until a reboot :p

11:34 <leio> is VRR supported by the dcp firmware?

07:23 <jannau> dottedmag: for now the swaps are immediate and blocking so you have a rough idea when the previous one was. the FW interface has timestamps, supposedly for VRR and async swaps. The driver doesn't use that yet and I haven't really looked into how that fits into drm/kms

11:03 <marcan> there's probably some weird reason DCP cares about calendar time, but it's probably not for VRR timing related stuff

10:40 <handlerug> hm, say I want to look at making VRR work. I probably should look around with m1n1 in hypervisor mode and check the packets the macOS drivers send, right?

11:30 <chadmed> jannau might have a better idea of what exactly needs to be done, but the gist of it aiui is that the hardware timestamps frames (expected) but we dont handle it in the driver and dont tell the drm subsystem that we can do VRR

11:27 <chadmed> DCP is our display controller, and VRR is variable refresh rate

11:26 <chadmed> you can add VRR to DCP if youre feeling adventurous ;)

00:26 <chadmed> only thing i can think of is that 1hz mode that comes with VRR, macos very aggressively uses that