[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: wine-bugs(a)winehq.org ReportedBy: CFSworks(a)gmail.com 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=33396 --- Comment #1 from Sam Edwards <CFSworks(a)gmail.com> 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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=33396 --- Comment #2 from Sam Edwards <CFSworks(a)gmail.com> 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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=33396 --- Comment #3 from Henri Verbeet <hverbeet(a)gmail.com> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=33396 --- Comment #4 from Sam Edwards <CFSworks(a)gmail.com> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=33396 --- Comment #5 from Henri Verbeet <hverbeet(a)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.
https://bugs.winehq.org/show_bug.cgi?id=33396 --- Comment #6 from Austin English <austinenglish(a)gmail.com> --- 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). -- 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.
participants (1)
-
wine-bugs＠winehq.org