I have a Lenovo W520 laptop with the nVidia GF108 (Quadro 1000M) chipset running RedHat OpenClient 6. I installed the RedHat RPM of the 275.28 driver (all that is available) and all works - nvidia-settings has a choice of 17 video modes plus "auto", with the default panel resulution of 1920x1080.

This is ancient, and also, the ability to switch to the second output via hotkey does not work. The notes for 302.17 indicated better support in that regard, so I installed that driver from the .run file.

All works great, with one exception: The only video mode offered is 1920x1024, which makes this basically useless to me. To support external devices (projectors, etc.) I need to downres the on-board to match, and then overlay the two in twinview (or toggle with the hotkey, if it were to work . . .). Virtual machines on the box don't seem to tolerate a res change without hanging, so I need to be able to set this *before* I go to the second port.

As a lark, I also tried the 295.59 driver, and while I have not yet been able to test the hotkey functionality, the modes are all present in this driver.

The only interesting thing that may have some bearing on this is that the 275* and 295* drivers all get this message in the Xorg logfile:

The 302.17 driver does not - it appears to be enforcing the sync rate it gets from EDID. To this end, I disabled the use of sync rates from EDID with UseEdidFreqs 0 in the config, and verified that the driver log showed that it was being applied. Still no modes. I tried forcing "UseImplicitMetaModes" even though it should be default. Nada. I tried forcing the modes with a Modeline, and that is ignored as well - despite the same clock range as was in the prior config file (that works!) this driver will not allow even a forced mode to support one of these additional resolutions.

I have attached the output of nvidia-bug-report.sh for both the working and non working drivers (295* and 302*) named accordingly.

Oh, and the EDID info for this display, as captured by nvidia-settings, and expanded with edid-decode is:
Extracted contents:

Attached. I see the issue, I think . . . for some reason, 302.17 thinks it should invalidate anything that it didn't get from EDID, despite the fact that they work fine in older drivers. That, and I can't find an option that screams out at me to short circuit this seemingly ignorant behaviour . . .

At any rate, I think I see the issue, and it would appear to be what I will call a "misfeature" that I have no idea how to disable - it thinks that it should *ONLY* use modes from the EDID, rather than all VESA modes as well. Log excerpt follows . . .

Sorry this change in behavior caught you off guard; the change is intentional, but there will be some growing pains while tools evolve to accomodate the new behavior.

For digital display devices, such as your laptop panel, the driver only sends it modetimings that the display device claims to support in its EDID. In drivers before 302.xx, the driver would lie and tell the X server and the rest of the system that it was driving whatever mode you asked for, even though under the hood the driver was sending one of the EDID modes to the display device. This discrepancy caused a variety problems and confusion (e.g., the mode advertised to the system could have a different refresh rate than what was actually being sent to the display device).

To make things more explicit, we altered the driver in 302.xx such that:

(a) The list of modes, advertised through nvidia-settings, the MetaMode syntax, RandR, etc, that can be driven to any display device is limited to what the driver will really send to the display device; in your example, this means the mode list will only contain 1920x1080.

(b) The MetaMode syntax is extended, such that you can separately configure the "ViewPortIn" and "ViewPortOut" to use in combination with any mode (we hope to eventually add RandR output properties for this, too).

With the display engine in NVIDIA GPUs, there are actually three different resolutions that are interesting: the resolution of the mode being sent to the display device, the resolution (and position) of the region within the mode in which to display pixels (this is "ViewPortOut"), and the resolution of the region within the X screen from which to fetch pixels (this is "ViewPortIn"). "ViewPortOut" would be used if you wanted your image to be smaller than the 1920x1080 mode (e.g., if you wanted a black border around your image, to do overscan compensation); that is probably not too interesting in your case. "ViewPortIn" can be used to configure a resolution smaller (or larger) than your mode and I think is what you want in your case.

E.g., if you want to display a 1024x768 resolution, scaled, on your 1920x1080 laptop panel:

"1920x1080 { ViewPortIn=1024x768 }"

If you want to aspect scale 1024x7868 (put black pillars on the left and right sides, so that the 1024x768 image keeps its aspect ratio):

"1920x1080 { ViewPortIn=1024x768, ViewPortOut=1440x1080+240+0 }"

If you want to center, rather than scale, the 1024x768 image within the 1920x1080 mode:

"1920x1080 { ViewPortIn=1024x768, ViewPortOut=1024x768+448+156 }"

The MetaMode syntax can have display device qualifiers and describe what you want on each display device. E.g., if you are connected to a VGA projector:

"DFP: 1920x1080 { ViewPortIn=1024x768 }, CRT: 1024x768"

Or have a 1920x1080 image scaled to fit the VGA projector:

"DFP: 1920x1080, CRT: 1024x768 { ViewPortIn=1920x1080 } "

Note that all of the above MetaModes can be specified on the nvidia-settings commandline, starting in 302.xx; e.g.,

The syntax is pretty powerful and flexible, but it requires a little getting used to. We also have work to do to update the nvidia-settings GUI to be aware of all of this. We also hope to update nvidia-settings such that it presents more resolutions to the user, by automatically creating MetaModes such as the above. There is also some work to be done to make the above work better with Wine and SDL-based fullscreen games.

I found (and tried) that and have had zero success - any of the MetaModes I attempt to define are also ignored. Part of the issue is that the README gives snippets of the commands, but very few complete examples in an xorg.conf file structure.

The log showed it to have been cleanly parsed, but as far as the modes and ability to use them, I could find no evidence anywhere that the 1024x768 metamode was available.

In nvidia-settings, in 295 and below, the Server Display Config section has a tab "X Screen" on which modes can be seen and selected. With 302, that tab does not exist, and there are no choices in the Resolution drop down either (which makes sense - it's a mode, not a resolution) so I am at a loss as to how to actually use these modes with this version?

UPDATE: I have made some progress on this . . . I noted that the case on my "MetaModes" line was incorrect, and altered. I now have the line:

And when you hit apply to enable any of these modes, nvidia-settings seems happy (shows the new boundaries of the mode on the graphic, etc.), but nothing on the screen actually changes.

I believe that I have the syntax correct based on what you sent, but no-joy.

I note that if I save the config file, it writes a different syntax for the metamodes - 1920x1080@1024x268 . . . with the incorrect value as seen above. I'll try that option line and see what gives . . .

It really would be nice to just have a setting that enables the old behaviour. While I don't deny that this fixes some bugs, for those of us with no bugs, it severely overcomplicates things by requiring a lot of "heavy lifting' in the xorg.conf file that was not needed before. That, or have the driver offer the VESA modes that were there in older versions as MetaModes - the bottom line is that I feel that it is not realistic to require this level of work by the end user to get back to the same behaviour that the driver has had for years . . . (I note later that you said that would be coming - any idea of timeline? As it stands, it's not exactly user friendly . . . )

And any additional suggestions *OTHER* than the README (which has failed me badly on this) as to specific useage and syntax would be great . .

Which indicated that what I entered was correct. nvidia-settings still shows the mangled values, and does not facilitate a change of modes.

The good news is that nvidia-settings --assign CurrentMetaMode *IS* now setting things correctly, so I have *FINALLY* gotten the 302 driver to at least admit to being able to do what I need.

The issue now is getting the toolset such that when I need to reres to match a projector to make a presentation, it isn't a 10 minute science project to get the main display down to projector resolution so that things fit, and to do it in under an hour . . . .

Unfortunately the nvidia-settings display configuration page hasn't been updated yet to be aware of ViewPortIn, so it isn't going to be helpful in this case. We hope to address that soon. Also, we hope to update the display configuration page such that it offers a list of common resolutions, supplementing the current list of resolutions in the "Resolution" drop down. When those fake resolutions are selected, nvidia-settings will generate a MetaMode with the correct ViewPortIn configuration. I'm sorry we don't have that, yet.

I think one thing that is causing confusion is the distinction between "mode" and MetaMode. The X driver's log messages are a bit sloppy about this, which doesn't help (I'll try to get that cleaned up, too). Anyway:

* A "mode" is the set of timings to drive to the monitor; this contains size, refresh rate, blanking periods, etc. With current 302.xx drivers, the "Resolution" drop down is giving the list of available modes.

* A "MetaMode" defines what mode should be used on each monitor, where each monitor should be positioned in the desktop, the ViewPortIn to use with each mode on each monitor, etc.

It kind of sounds like you were expecting that when you put multiple MetaModes in your MetaModes X configuration option, each would be listed as an option in the Resolution drop down of nvidia-settings. A MetaMode has wider scope than that; it won't affect the list of resolutions per monitor in nvidia-settings. Sorry that was unclear.

The MetaModes X configuration option is a semi-colon separated list of MetaModes. You can switch between MetaModes through the old-school XF86VidMode X extension (e.g., `xvidtune -prev` or `xvidtune -next`) or through the key combination ctrl-alt-plus or ctrl-alt-minus. Further, the nvidia-settings display configuration page, or `nvidia-settings --assign CurrentMetaMode="foo"`, overwrites the current MetaMode in the list of MetaModes that you specified in your X configuration file.

Anyway, putting multiple MetaModes in your X configuration file is probably not the easiest method. For what you're trying to do, for right now probably the simplest solution is to write a few scripts that invoke nvidia-settings with canned CurrentMetaModes values. E.g.,

Thanks again for the attention. I was not expecting the modes to appear in the resolution drop down, but rather in the X Screen advanced window list of modes, where they can be selected and applied, and that is where they are appearing mangled. As noted, the reported modes with ViewPortIn settings log correctly in the Xorg log file, so I think my entries are correct . . . it's just that the easiest tool to use to manipulate them at this point (nvidia-settings) gets them wrong graphically, and will not apply a mode when selected, again graphically. Nvidia-settings from the cli works fine . . . .

At any rate, I can now make this work. I still question the change of a behaviour that likely very few folks ever had much trouble with, for one which, at present, is a PITA. At least consider a flag in the drive config to release the restriction, and allow the VESA modes to also be used - it is apparent from viewing the mode debug data that the driver is still polling those modes . . .

At any rate, for now, I think I'll just stay on the 295 builds, and wait for progress in the 302 series . . . the benefits are almost undetectable compared to the liabilities of upgrading at this point in the 302 driver and tooset's maturity.

RandR 1.x (x >= 2) works in terms of modes on individual outputs, whereas a MetaMode defines the configuration of all outputs on the X screen including "meta" information like viewport configuration to use with a mode.

With 304.22, MetaModes are selectable through RandR 1.1 protocol. So, if you run `xrandr -q --q1` you should see the MetaModes you configured (well, RandR 1.1 only sees the size of the MetaMode, so I expect you'd see 1440x900, 1024x768, 800x600, 640x480), and you can set those with the RandR 1.1 `xrandr -s SIZE`. SDL/Wine generally use either RandR 1.1 or XF86Vidmode to set the mode for a fullscreen game, so 304.22 should give more resolution options to fullscreen games.

We also enhanced the "IncludeImplicitMetaModes" X configuration option in 304.22 to make additional MetaModes available to RandR1.1/XF86Vidmode clients.

But, yes: we still need to make nvidia-settings aware of viewport configuration.