Non-native resolutions not available in 3xx drivers on 8700M GT

I’m running Linux Mint (13/Maya and 14/Nadia) on a Dell M1730 laptop with dual 8700M GT GPUs and a 17" 1920x1200 Seiko/Epson built-in LCD panel.

With the 2xx series drivers, I could change resolutions to any of the standard 4:3/16:9/16:10 VESA/SVGA ones from 640x480 up through the native resolution of 1920x1200.

With the 3xx series (304 and 310), I only have the option of running at the native resolution of 1920x1200. nvidia-settings and xrandr do not allow any other modes to be set, and applications that try to change the resolution report that they cannot do so.

I have also noticed that GPU scaling options are mission from the 3xx series drivers, which is significant to me because my laptop display does not have an OSD for configuring aspect ratio scaling. I am therefore dependent on the GPU to do this for me.

Running a 2xx version is not a viable workaround for this issue, as the Steam Linux beta client requires that I use a 3xx series driver.

Thing I’ve tried, without success:

  • switching back and forth between 2xx and 3xx versions using the “additional drivers” and/or “software sources” utilities in Linux Mint. The issue is consistently present with the 3xx versions and consistently non-present with 2xx versions.
  • running nvidia-settings as both root and user, and nvidia-xconfig as root, and allowing them to save settings to their respective files. This does not help before or after rebooting.
  • using nvidia-xconfig’s --mode parameter to add modes like 640x480 (they still don’t show up, even after a reboot).

I’m having the same problem. [url]http://www.winehq.org/pipermail/wine-devel/2012-September/096933.html[/url] more or less explains the situation.
Previously the default resolutions were just added as modes and internally scaled up to the native resolution. As far as I understand it, this leads to incorrectly reported refresh rates for the modes. Now just the modes reported by the monitor are exposed and it is up to the user (for example a game) to use randr to set the desired resolution, which is then scaled up to the native resolution.

The way it works now is more “correct” than the old behavior, but what the user sees is that the old way worked and the new does not. As long as everything except nvidia does not use the “correct” way, I consider it a bug to stubbornly stick to it. There should at least be a switch in xorg.conf to get the old behavior back.

Thanks.

Ridiculous that they don’t provide metamode definitions for common non-native modes, resulting in even nvidia-settings only showing the native resolution as an option. Also, I wonder if Wine is able to set those metamodes, or will I still be out of luck after defining them?

More useful information:
ftp://download.nvidia.com/XFree86/Linux-x86/310.19/README/configtwinview.html
http://www.nvnews.net/vbulletin/showthread.php?t=179892

I have laptop with native 1600x900 and starting to grind my teeth with this new change. I am able to use other resolutions with games in wine by using the viewport command and then setting a virtual desktop in wine with the same resolution but this is really a pain. Everything used to be so simple! Also, the Unity desktop doesn’t scale with the viewports so parts of it get cut off, (panning set correctly).

They do provide modes for non-native resolutions. But only to xrandr1.1 and the xvidmode extension. You can see the modes with

xrandr --q1

and switch to them with

xrandr -s YYYxZZZ

Then there’s a (admittedly not cool) workaround for wine - compile it without xrandr support. There was no problem in the past because wine used xrandr1.1, but recently they switched to xrandr1.2.

All in all though, I do agree Nvidia should provide non-native modes also via xrandr1.2

RandR 1.2 gives complete control of the display configuration, including choosing the actual mode timings to send to the display and how the desktop should be scaled to that resolution, to the X client applications (i.e. Wine in this case). When an application chooses to use RandR 1.2 requests rather than RandR 1.1 requests, it is assuming control of that configuration and needs to handle all of the options users might want to configure, including scaling.

Are you saying every xrandr1.2 app should re-implement all the stuff to handle non-native resolutions itself? Seems very, very inefficient to me. I don’t think it’ll happen, also because other xrandr1.2 drivers handle this in the driver, and expose scaling options as xrandr properties.

That also means I have to configure scaling separately in every application (assuming there would every be an application working correctly with the current nvidia driver). It might be technically nicer to do it the new way, but the user experience is much worse. Are you writing the driver to be used, or to win some software design award?
I hope you do the same as you did with the “blue skin” bug in flash and just make it work instead of waiting indefinitely for application writers to change their software.

You have to understand that from an end-user perspective, it’s completely broken:

  • The official version of Wine in the Ubuntu/Mint repositories cannot change resolutions.
  • nvidia-settings shows only the native resolution as an option.

From a specifications standpoint, the drivers might be doing everything right. That doesn’t mean that it’s resulting in something usable out of the box for end-users, which should be a critical concern.

Wine actually disabled RandR 1.2/1.3 because of this.
http://source.winehq.org/git/wine.git/commit/8776e1c0e1597fec169d169888660deb5bb08c2c

Thanks, I love the code comment:

+    /* Recent (304.64, possibly earlier) versions of the nvidia driver only
+     * report a DFP's native mode through RandR 1.2 / 1.3. Standard DMT modes
+     * are only listed through RandR 1.0 / 1.1. This is completely useless,
+     * but NVIDIA considers this a feature, so it's unlikely to change. The
+     * best we can do is to fall back to RandR 1.0 and encourage users to
+     * consider more cooperative driver vendors when we detect such a
+     * configuration. */

This has been explained to Henri in the past, so I’m sorry to hear that he still believes so vehemently that the graphics driver is the right place for this sort of workaround. However, I’m glad to hear that Wine will work correctly again.

Aaron, put yourself in the shoes of a user. They had this stuff work - the list of resolutions had all the desired entries and there was a simple setting for scaling. Now this stuff doesn’t work anymore. You can explain to the user the technical background but it doesn’t make much difference - from their perspective, the stuff still doesn’t work.

Also, Intel and AMD and probably nouveau do handle this in the driver. With those drivers, xrandr1.2 shows non-native resolutions being available and there’s a property to set scaling. The driver then does all the necessary gymnastics itself and the user gets what they wanted.

I’m a Linux novice, but after a search of the web came up with something that worked for me.
The Linux distribution is Ubuntu 12.04
The machine is a Dell XPS M1730 running two Nvidia 8700m GT video cards.

What to do:
Download the appropriate driver from NVidia.
For me, that was NVIDIA-Linux-x86_64-319.17.run

You’ll need log in as root and shut down the X server.
Open a terminal window and enter
$ sudo -s
That, after you’ve entered your password, should have you logged in as root.

To shut down X, run the command

service lightdm stop

That should take you to a ‘black’ screen, with just a command prompt.

To install the driver, run

sh whatever-driver-you-downloaded

NVidia’s driver install program will prompt you through the set up.
Give it a minute when complete to reconfigure everything, and it then takes you back to a command prompt (look at the bottom of the screen).

Restart the XServer by running

service lightdm start

From a terminal window, you can now run
$ nvidia-settings
and all the non-native resolutions should be available.

Worked for me - hope it works for you.