Yes, like Aaron said: The ViewPort{In,Out} configurability is much more flexible and powerful, because you can choose what modetimings to drive to the display device independently of what sized region to read from the X screen, and how to scale that region within the modetimings. But, it is admittedly pretty low level and we can layer higher level tools for simpler configuration on top of it.

Liacon: for your uses, how do you normally choose between the modes that you would like aspect-scaled? E.g., are you using an application that uses the old XV86VidMode extension? Are you switching between MetaModes that you configured in your xorg.conf? An X log with ModeDebug=True (`nvidia-xconfig --mode-debug`) from 295.xx might help illustrate your usage.

Gusar: thanks for the point about the "scaling mode" output property. I assume in that case, the "mode" (set through xrandr's '--mode') is actually the ViewPortIn size, and the driver infers the actual mode (what the monitor receives), presumably using the preferred timing as reported by the EDID. I would be reluctant to reinterpret the mode as ViewPortIn size, but we can look into similar sorts of things.

Lastly, for the problems with "DFP-0: 1920x1200 { ViewPortIn=2560x1600}", there is currently a bug where RRGetCrtcInfo isn't correct for custom ViewPortIns. I suspect your window manager is looking at the RRGetCrtcInfo information and clamping your windows to that size. We'll hopefully fix that soon.