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

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

Bug #: 33396
           Summary: GetSystemMetrics always reports native resolution with
                    --with-xinerama.
           Product: Wine
           Version: 1.5.28
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winex11.drv
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

As the summary says, GetSystemMetrics(SM_C{X,Y}SCREEN) always reports the
native resolution, even if an application changes the resolution, unless I
configure Wine with the --without-xinerama option. This can be seen when I run
D3D9 device tests, leading to test failures (see attachments).

I am on the NVIDIA proprietary driver version 313.18, which may be relevant as
this driver does have the "broken" XRandR 1.2. I cannot test with Nouveau
because it doesn't support my GPU.

Even if this is the proprietary driver's fault, I'm still opening this bug on
the WineHQ Bugzilla to track its resolution here, and provide information to
the NVIDIA developers if we do have to report it to them.

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

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

--- Comment #1 from Sam Edwards  2013-04-14 20:32:58 CDT ---
Created attachment 44190
  --> http://bugs.winehq.org/attachment.cgi?id=44190
d3d9_test.exe device, with xinerama support

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

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

--- Comment #2 from Sam Edwards  2013-04-14 20:33:17 CDT ---
Created attachment 44191
  --> http://bugs.winehq.org/attachment.cgi?id=44191
d3d9_test.exe device, without xinerama support

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

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

--- Comment #3 from Henri Verbeet  2013-04-15 05:10:02 CDT ---
Yeah, that's just NVIDIA RandR being broken. Note that afaik it's limited to
display panels without a hardware scaler (which typically means laptops), so
you may get better results when you attach an external monitor. As far as I'm
aware NVIDIA already knows about the issue, but doesn't consider it their
problem.

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

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

--- Comment #4 from Sam Edwards  2013-04-18 01:46:07 CDT ---
(In reply to comment #3)
> Yeah, that's just NVIDIA RandR being broken. Note that afaik it's limited to
> display panels without a hardware scaler (which typically means laptops), so
> you may get better results when you attach an external monitor. As far as I'm
> aware NVIDIA already knows about the issue, but doesn't consider it their
> problem.

I looked at their discussion on wine-devel. They seem to be more focused on the
purity of their XRandR 1.2 interface than apathetic about bugs. That is, they
want the XRandR 1.2 configuration to control the physical signal being sent to
the monitor rather than the size of the "screen" (in X11 terminology). It's not
a bug in the driver, but rather the developers are trying to be really "exact"
about their implementation. (I make no judgement on whether this design is good
or bad, but I'd still like to make Wine work with it regardless.)

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.

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.

That said, should this be reported to NVIDIA as a bug, or worked-around in
Wine? I'm in favor of the former, but at a loss for how to get in contact with
them.

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

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

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

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

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

--- Comment #6 from Austin English  ---
This is your friendly reminder that there has been no bug activity for over a
year. Is this still an issue in current (1.7.37 or newer) wine? If so, please
attach the terminal output in 1.7.37 (see http://wiki.winehq.org/FAQ#get_log).