[Bug 33396] GetSystemMetrics always reports native resolution with --with-xinerama.

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=33396

--- Comment #5 from Henri Verbeet <hverbeet at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.