http://bugs.winehq.org/show_bug.cgi?id=33396
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2013-04-18 04:14:23 CDT --- (In reply to comment #4)
XRandR 1.0 still determines the screen mode, so using the 1.0 interface into their driver allows reconfiguration of the screen (not the monitor) even if the monitor doesn't support it, because it implicitly sets up scaling and letterboxing appropriately.
There are a couple of problems with that approach. One of the reasons for using RandR 1.3 is that it allows you to use cached information about the state of the displays instead of probing the actual hardware every time. Another reason is that it actually allows you to control individual displays in a multihead setup.
Note that the RandR 1.0 interface is somewhat broken in current versions of the driver as well though. It sets up scaling and clipping, but (perhaps obviously) doesn't change the size of (X11) screen. That means that if you set e.g. a 1024x768 mode on a 1920x1200 display through RandR 1.0, you'll still conceptually have a 1920x1200 desktop, but you won't be able to access for example the taskbar on a typical desktop. (Not resizing the desktop on mode changes could be considered a feature in some cases, but that should be a window manager / desktop decision, not the result of a broken RandR implementation.)
However, Xinerama is concerned with screen/desktop, not monitor/CRTC, so the fact that my physical monitor size is coming back from Xinerama is most likely a bug.
It might be, but it could also just be the result of not actually changing the screen size. It probably doesn't really matter if it's a RandR or a Xinerama issue though.
Ultimately I'm not sure how much we should really care as a project. I think this is mostly something between nvidia and their customers, and at this point there are probably enough alternatives, both in terms of drivers and in terms of hardware, albeit all with their own sets of tradeoffs.
One thing I would like to explicitly note in the above is that when I use "broken", that's mostly a usability consideration. It's probably a perfectly legal implementation of RandR 1.3 to only ever report a single display mode; it just isn't a very useful one. I.e., the tests that depend on changing display modes would / should probably just skip if we actually used RandR 1.3 on current nvidia drivers, but any actual applications that depend on modes like 800x600 or 1024x768 always being available would just break.