Xrandr reports wrong refresh rate

[davelaser]

sam@spitfire:~$ nvidia-settings -nt -q RefreshRate
59.95 Hz

The refresh rate for my monitor is 59.95 hz. The nvidia driver reports wrong refresh rates and possible modes when queried via xrandr:

sam@spitfire:~$ xrandr 
Screen 0: minimum 320 x 175, current 1920 x 1200, maximum 1920 x 1200
default connected 1920x1200+0+0 0mm x 0mm
   1920x1200      50.0* 
   1920x1080      51.0  
   1680x1050      52.0     53.0  
   1600x1200      54.0  
   1600x1024      55.0  
   1440x900       56.0  
   1400x1050      57.0     58.0     59.0  
   1360x768       60.0     61.0  
   1280x1024      62.0     63.0     64.0  
   1280x960       65.0     66.0  
   1152x864       67.0     68.0     69.0     70.0     71.0     72.0     73.0  
   1024x768       74.0     75.0     76.0     77.0     78.0     79.0  
   960x720        80.0     81.0  
   960x600        82.0  
   960x540        83.0  
   928x696        84.0     85.0  
   896x672        86.0     87.0  
   840x525        88.0     89.0     90.0     91.0     92.0  
   832x624        93.0  
   800x600        94.0     95.0     96.0     97.0     98.0     99.0    100.0    101.0    102.0    103.0  
   800x512       104.0  
   720x450       105.0  
   720x400       106.0  
   700x525       107.0    108.0    109.0    110.0  
   680x384       111.0    112.0  
   640x512       113.0    114.0    115.0  
   640x480       116.0    117.0    118.0    119.0    120.0    121.0    122.0    123.0  
   640x400       124.0  
   640x350       125.0  
   576x432       126.0    127.0    128.0    129.0    130.0    131.0    132.0  
   512x384       133.0    134.0    135.0    136.0    137.0  
   416x312       138.0  
   400x300       139.0    140.0    141.0    142.0    143.0  
   360x200       144.0  
   320x240       145.0    146.0    147.0    148.0  
   320x200       149.0  
   320x175       150.0

This has been an issue for as long as I can remember with the binary drivers, I get the problem both on a geforce 7400m and a 8800gt. It is not a harmless bug because a lot of X applications use randr for querying the refresh rate in order to implement internal frame limiting. Compiz for example limits the frame rate internally to 50hz instead of 60hz if I let it detect the frame rate automatically, this makes animations and window moving jerky. XBMC also has problems with this and caused stuttery animations and video when using the nvidia driver.

Putting the following line in the device section of my xorg.conf appears to fix the problem and causes randr to report the correct rates:

Option         "DynamicTwinView" "False"

This should not make a difference as I am only using one monitor anyway. Reported modes after disabling dynamic twinview are below:

sam@spitfire:~$ xrandr 
Screen 0: minimum 320 x 175, current 1920 x 1200, maximum 1920 x 1200
default connected 1920x1200+0+0 0mm x 0mm
   1920x1200      60.0* 
   1920x1080      60.0  
   1680x1050      60.0  
   1600x1200      60.0  
   1600x1024      60.0  
   1440x900       60.0  
   1400x1050      75.0     70.0     60.0  
   1360x768       60.0  
   1280x1024      85.0     75.0     60.0  
   1280x960       85.0     60.0  
   1152x864      100.0     85.0     75.0     70.0     60.0  
   1024x768       85.0     75.0     70.0     60.0     87.0  
   960x720        75.0     60.0  
   960x600        60.0  
   960x540        60.0  
   928x696        75.0     60.0  
   896x672        75.0     60.0  
   840x525        85.0     75.0     70.0     60.0  
   832x624        75.0  
   800x600        85.0     75.0     72.0     60.0     56.0     70.0     65.0  
   800x512        60.0  
   720x450        60.0  
   720x400        85.0  
   700x525        85.0     75.0     70.0     60.0  
   680x384        60.0  
   640x512        85.0     75.0     60.0  
   640x480        85.0     75.0     73.0     60.0  
   640x400        85.0  
   640x350        85.0  
   576x432       100.0     85.0     75.0     70.0     60.0  
   512x384        85.0     75.0     70.0     60.0     87.0  
   416x312        75.0  
   400x300        85.0     75.0     72.0     60.0     56.0  
   360x200        85.0  
   320x240        85.0     75.0     73.0     60.0  
   320x200        85.0  
   320x175        85.0

This issue has been around for years and probably causes widespread problems with a lot of opengl X applications that use randr to query the display mode, any timeline on when it might be addressed?

Sam

[AaronP]

The purpose of DynamicTwinview is to allow you to dynamically add a second screen without restarting X. That's why it makes a difference even if you start with only one display attached.

[davelaser]

Originally Posted by AaronP

The purpose of DynamicTwinview is to allow you to dynamically add a second screen without restarting X. That's why it makes a difference even if you start with only one display attached.

Ok, but can it be fixed so that the correct refresh rate is reported when dynamic twinview is enabled but only one monitor is connected? nvidia-settings -q reports the correct mode, xrandr reports something different, surely this is a bug?

[AaronP]

No. The problem is that the NVIDIA driver has to make each metamode look unique to the X server. With DynamicTwinview enabled, you could add a metamode that clones two monitors with the exact same size and refresh rate as the single-display metamode. To the X server, these would appear as the same mode. The driver has to make the modes look unique, and the refresh rate field is the only way to do it.

You can query the actual refresh rates of the display devices in a metamode through the NV-CONTROL extension.

[davelaser]

Originally Posted by AaronP

No. The problem is that the NVIDIA driver has to make each metamode look unique to the X server. With DynamicTwinview enabled, you could add a metamode that clones two monitors with the exact same size and refresh rate as the single-display metamode. To the X server, these would appear as the same mode. The driver has to make the modes look unique, and the refresh rate field is the only way to do it.

You can query the actual refresh rates of the display devices in a metamode through the NV-CONTROL extension.

This sounds like a bit of a hack. The open source drivers manage to do dualhead whilst still reporting the correct mode to the X server, this seems to be one of the (very) few areas where they are better than the binary driver. Is this something that will be resolved when the nvidia driver finally gets proper randr support?

[AaronP]

This behavior has existed in the NVIDIA driver since before RandR 1.2, which is simply a different way to provide the same functionality as NV-CONTROL. We do still have plans to add support for the new RandR eventually, but since NV-CONTROL already provides most of the same functionality, it's been a low priority.

[davelaser]

Not to moan, but proper randr support has been promised for almost three years now. I won't be holding my breath.

[dura91]

I found the explanation here: http://www.mythtv.org/wiki/User_Manual:JudderFree
With correct refresh rates it is not possible to have for example 24hz and 23.976hz because xrandr only accept integer refresh rates. The NVidia driver behaviour is a workaround to allow this.

[jusst]

Is there actually a way to get a list of "virtual refresh rate" -> real refresh rate relations?
So that one would know which of the xrandr-listed modes is which real mode?
This would help to allow video playback applications selecting the best mode automatically.

[AaronP]

Originally Posted by jusst

Is there actually a way to get a list of "virtual refresh rate" -> real refresh rate relations?
So that one would know which of the xrandr-listed modes is which real mode?
This would help to allow video playback applications selecting the best mode automatically.

Yes, you can do this through the NV-CONTROL extension. The ID number for each metamode is the RandR 1.1 "refresh rate".

There's an example of how to do it in the nvidia-settings source code 'samples' directory. Build the samples, then run `./nv-control-dpy --print-metamodes`. You can extract the modes from each metamode. Also try `./nv-control-dpy --print-used-modelines`.