XRandr refresh rates show incorrect results

[clearer]

I have seen that nVidia drivers show incorrect refresh rates for quite some time now so I decided to file a bug report on it (if you think this should be somewhere else -- please, do tell).

My monitor supports up from 60.1Hz to 85.0Hz, yet Xrandr reports up refresh rates from 50.0 to 170.0Hz. I used the x.org provided xrandr command to check this and wrote my own program to make sure that the problem wasn't with some bug in xrandr -- both shows the same result.

I have not seen this issue on any other driver and I have seen this persistently since (at least) the early 9xxx drivers. This should be something that's easy to fix.

I tested this on a dual core x86_64 running a 32 bit kernel on Fedora 7. X -version reports

X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Fedora Core 7 Red Hat, Inc.
Current Operating System: Linux firefield.dk 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686
Build Date: 11 June 2007
Build ID: xorg-x11-server 1.3.0.0-9.fc7 
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Module Loader present

uname -a reports

Linux firefield.dk 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686 i686 i386 GNU/Linux

And finally, the installed drivers are:

100.14.11

If there is already a report for this bug, I apologize -- I couldn't find it on the forums.

[clearer]

My test program was:

#include <X11/Xlib.h>
#include <X11/extensions/Xrandr.h>
#include <iostream>

using namespace std;

int main(int argc, char **argv)
{
	XRRScreenSize *sizes;
	int counter_sizes;
	int counter_rates;
	short* rates;
	
	Display *display;
	int screen;
	Window root;
	if (display == 0)
		cerr << "Could not open connection to X server." << endl;

	display = XOpenDisplay(0);
	screen = DefaultScreen(display);
	root = RootWindow(display, screen);
	sizes = XRRSizes(display, screen, &counter_sizes);
	for (int i = 0; i < counter_sizes; ++i)
	{
		rates = XRRRates(display, screen, i, &counter_rates);
		cout << sizes[i].width << "x" << sizes[i].height << ":\n";
		for (int j = 0; j < counter_rates; ++j)
			cout << rates[j] << ", ";
		cout << endl;

	}

	XCloseDisplay(display);
}

[netllama]

This is expected behavior, and is documented in the driver README.

[clearer]

Originally Posted by netllama

This is expected behavior, and is documented in the driver README.

In that case, please fix it.

[zander]

The behavior you're seeing is not a bug. Please see the FAQ and the DynamicTwinView X driver option's description in the README.

[clearer]

Originally Posted by zander

The behavior you're seeing is not a bug. Please see the FAQ and the DynamicTwinView X driver option's description in the README.

I have gone through the readme file from end to other to find something that fits what I am seeing. It most certainly is a bug. Even if there is a work-around, XRandR does not report the correct frequencies, by default when using nvidia's drivers, because of how the drivers work -- not XRandR.

The bug may not be in the drivers code, but then it certainly is in the algorithm used. Since it evidently is possible to actually poll the correct frequencies from the driver, if DynamicTwinview is turned off, then I see no reason why it shouldn't be possible to get them when it's on.

I repeat: this is a bug (unless of course, nvidia likes to write software that works in other ways than what people expect). I already have several other options included in my configuration file for X to work around other non-bugs of this driver -- several more should not be required.

[AaronP]

The FAQ entry zander referred to explains why it is necessary to make the refresh rates reported by the RandR extension unique. If you want to get the active refresh rates of your screens, you can use "nvidia-settings -q RefreshRate" or disable DynamicTwinview. As both he an netllama stated, this is not a bug.

[clearer]

Originally Posted by AaronP

The FAQ entry zander referred to explains why it is necessary to make the refresh rates reported by the RandR extension unique. If you want to get the active refresh rates of your screens, you can use "nvidia-settings -q RefreshRate" or disable DynamicTwinview. As both he an netllama stated, this is not a bug.

The fact that it is required for nvidia to bug RandR this way is not acceptable. I don't really care if I can use nvidia-settings to figure out which current rate I have -- sometimes it's simply not possible to disable DynamicTwinview all together, which means that this bug cannot always be worked around.

A documented bug, is still a bug -- regardless of how well written the documentation is or how many times you call it something else.

The facts are that when I use nvidia's drivers and I don't have DynamicTwinview turned off, I get incorrect results when probing the frequencies available using RandR -- as far as I know, it won't even work if I actually use DynamicTwinview for something.

No other driver have issues resembling this -- at all -- no-one else is forced to bug RandR to make things work. Why does nvidia have to do this?

[zander]

Again, the reasons are explained in the README. If you don't need dynamic TwinView, you can have the driver revert to its original (static TwinView) behavior; if you wish to take advantage of dynamic TwinView, however, you currently need to live with the limitations imposed by the RandR 1.x extension. I expect that as the next generation of RandR matures and is deployed, interaction between dynamic TwinView and RandR will improve. I'm not aware of other drivers that implement dynamic TwinView like functionality with RandR 1.x.

[clearer]

Xinerama springs to mind.

Regardless -- RandR does not provide the correct frequencies when dynamic twinview is turned on -- hence it's a bug (even if this is intentional or if it is documented). If not a bug in the code, then in the algorithm.

[pe1chl]

RandR can only handle a list of screen/resolution/frequency where each of them have to be unique. So you cannot have different options with the same resolution and frequency, which is why the NVIDIA driver assings a fake frequency to different modes with the same resolution.

If you want to call it a bug, it is a bug in the capabilities of RandR. You could call it a bug in the RandR 1.x specification.

Switch off the Dynamic Twinview or the entire Twinview and your problem will be solved. Twinview is an optional extra of the NVIDIA driver that you can switch off, I did that too.

[clearer]

I am aware of the limitations of RandR. The problem is that the nvidia drivers by default makes RandR report incorrect results, in order to support something the vast majority doesn't use (or has any need for). The few who does need it and uses it, should be quite capable to get it working with no hassle (or have someone around who knows and can get it going).