So it turns out that the problem is that the modesetting driver is pruning these modelines because it thinks their vertical refresh is greater than the max vrefresh.
The function in question is hw/xfree86/drivers/modesetting/drmmode_display.c#add_gtf_modes(), and it is calculating refresh rates between 65 and 85 but thinks that the max vrefresh is 60.599998 because of these lines:
However, I can see from the MonPtr variable passed to hw/xfree86/modes/xf86Modes.c#xf86ValidateModesSync() that the driver has figured out a range of 56.25 to 120 for this screen, so my guess is that it shouldn't be restricting the max to 60 plus 1% in add_gtf_modes().
Looking at get_modes(), which calls add_gtf_modes(), it is also extracting a MonPtr variable from the EDID, so perhaps it could pass this pointer to add_gtf_modes() and add_gtf_modes() could use the actual maximum vertical refresh for the monitor instead of locking it to 60.
Thanks for the info.
So it turns out that the problem is that the modesetting driver is pruning these modelines because it thinks their vertical refresh is greater than the max vrefresh.
The function in question is hw/xfree86/ drivers/ modesetting/ drmmode_ display. c#add_gtf_ modes() , and it is calculating refresh rates between 65 and 85 but thinks that the max vrefresh is 60.599998 because of these lines:
max_vrefresh = max(max_vrefresh, 60.0);
max_vrefresh *= (1 + SYNC_TOLERANCE);
However, I can see from the MonPtr variable passed to hw/xfree86/ modes/xf86Modes .c#xf86Validate ModesSync( ) that the driver has figured out a range of 56.25 to 120 for this screen, so my guess is that it shouldn't be restricting the max to 60 plus 1% in add_gtf_modes().
Looking at get_modes(), which calls add_gtf_modes(), it is also extracting a MonPtr variable from the EDID, so perhaps it could pass this pointer to add_gtf_modes() and add_gtf_modes() could use the actual maximum vertical refresh for the monitor instead of locking it to 60.