http://bugs.winehq.org/show_bug.cgi?id=34348
Bug #: 34348 Summary: Wine xrandr12 failure Product: Wine Version: 1.6 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: wolterh6@gmail.com Classification: Unclassified
Every time I run an application through wine, I get the terminal output I attach to this bug. This prevents most applications from even running at all.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #1 from Wolter Hellmund wolterh6@gmail.com 2013-08-24 20:38:24 CDT --- Created attachment 45723 --> http://bugs.winehq.org/attachment.cgi?id=45723 Terminal output of winecfg
http://bugs.winehq.org/show_bug.cgi?id=34348
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal
--- Comment #2 from Rosanne DiMesio dimesio@earthlink.net 2013-08-24 21:24:52 CDT --- Not a blocker. http://bugs.winehq.org/page.cgi?id=fields.html#importance
http://bugs.winehq.org/show_bug.cgi?id=34348
Wolter Hellmund wolterh6@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major
--- Comment #3 from Wolter Hellmund wolterh6@gmail.com 2013-08-24 22:00:44 CDT --- Sorry for the wrong label choice. It is not a "normal" either, changed to major because it represents a major loss of functionality for a wide range of applications.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #4 from Jerome Leclanche adys.wh@gmail.com 2013-08-24 22:26:59 CDT --- This is most likely an issue in your driver setup. What driver are you running? What version?
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #5 from Wolter Hellmund wolterh6@gmail.com 2013-08-25 14:58:34 CDT --- I am using nVidia proprietary driver version 304.88, on Ubuntu 13.04 amd64.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #6 from Rosanne DiMesio dimesio@earthlink.net 2013-08-25 18:53:22 CDT --- Try a clean wineprefix.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #7 from Wolter Hellmund wolterh6@gmail.com 2013-08-26 17:01:46 CDT --- I tried a clean prefix and the error persists
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #8 from Austin English austinenglish@gmail.com 2013-08-27 01:00:47 CDT --- (In reply to comment #7)
I tried a clean prefix and the error persists
Is the error just that terminal output? What programs don't work? Does 'wine notepad'? Does disabling xrandr help?
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #9 from Henri Verbeet hverbeet@gmail.com 2013-08-27 01:17:41 CDT --- That message is a driver issue, but it's unlikely to prevent most applications from running. The practical effect is that display mode changes will be slightly screwed up in general, and more so in multihead setups. The easiest way to avoid that is to use the Nouveau driver, though probably at the cost of some GL performance. Other options are using an AMD or Intel GPU, or trying to convince NVIDIA to fix the drivers.
Either way, as I said before, this is unlikely to prevent most applications from running, so you probably have a different issue as well.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #10 from Rosanne DiMesio dimesio@earthlink.net 2013-08-27 09:13:31 CDT --- We have lots of Nvidia users (including me) and that patch has been part of Wine for months, so if it were really preventing most apps from running I would have expected lots of bug reports and forum posts shortly after it was first committed. No one else has reported this, and I certainly haven't seen it on my system.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #11 from Wolter Hellmund wolterh6@gmail.com 2013-08-27 16:34:16 CDT --- (In reply to comment #8)
(In reply to comment #7)
I tried a clean prefix and the error persists
Is the error just that terminal output? What programs don't work? Does 'wine notepad'? Does disabling xrandr help?
None of my Steam games startup or a cam design software (Dynacam) I had to use, sorry for generalizing then, Henri and Rosanne. Notepad does work.
While I was searching how to disable xrandr, I checked my /var/log/Xorg.0.log and found the following line (163):
[ 41.267] (--) RandR disabled
It doesn't seem to have been triggered by any particular event, to what I can evaluate. I will attach my Xorg.0.log in case any of you wants to take a quick look.
http://bugs.winehq.org/show_bug.cgi?id=34348
Wolter Hellmund wolterh6@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #12 from Wolter Hellmund wolterh6@gmail.com 2013-08-27 16:35:10 CDT --- Created attachment 45754 --> http://bugs.winehq.org/attachment.cgi?id=45754 Xorg output
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #13 from Wolter Hellmund wolterh6@gmail.com 2013-08-27 17:29:11 CDT --- I have tried with drivers 304.88 and 310.44 now, but the error persists. Rosanne what driver do you use? I would like to try the same to prove if the driver is the culprit.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #14 from Wolter Hellmund wolterh6@gmail.com 2013-08-27 19:21:42 CDT --- I just tried the nVidia driver 325.15 and the error still exists.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #15 from Rosanne DiMesio dimesio@earthlink.net 2013-08-27 22:24:16 CDT --- I am using the 310.44 driver, card is 8400GS.
http://bugs.winehq.org/show_bug.cgi?id=34348
Andrey Lelikov winebug@lelik.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winebug@lelik.org
--- Comment #16 from Andrey Lelikov winebug@lelik.org 2013-09-12 01:10:05 CDT --- I see the same behavior on amd64 ubuntu 12, after I've updated to the latest nvidia proprietary driver - I've removed nvidia-current and installed driver directly from nvidia site. I'm only running command-line apps under wine, and this message still shows up.
http://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #17 from Andrey Lelikov winebug@lelik.org 2013-09-12 01:11:30 CDT --- Created attachment 45923 --> http://bugs.winehq.org/attachment.cgi?id=45923 wine output
https://bugs.winehq.org/show_bug.cgi?id=34348
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
--- Comment #18 from Adam Bolte abolte@systemsaviour.com --- I've been using the latest stable Nvidia drivers with development releases of Wine for years without seeing this message. That is, until today when I compiled 1.7.35.
1.7.34 was running with nvidia 340.65 previously. When 1.7.35 started showing this, I upgraded my driver to 346.35 (also stable) released recently. No change in behaviour.
In 1.7.34, I was able to load Dead Space 3. However in 1.7.35, the game no longer runs with an error along the lines of my video card not meeting the game's minimum requirements.
Reverting commit 8e9e4a657f29ff018c6296ced1f115ca8731e5e6 allows the game to run again.
https://bugs.winehq.org/show_bug.cgi?id=34348
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #19 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Adam Bolte from comment #18)
I've been using the latest stable Nvidia drivers with development releases of Wine for years without seeing this message. That is, until today when I compiled 1.7.35.
1.7.34 was running with nvidia 340.65 previously. When 1.7.35 started showing this, I upgraded my driver to 346.35 (also stable) released recently. No change in behaviour.
In 1.7.34, I was able to load Dead Space 3. However in 1.7.35, the game no longer runs with an error along the lines of my video card not meeting the game's minimum requirements.
Reverting commit 8e9e4a657f29ff018c6296ced1f115ca8731e5e6 allows the game to run again.
Based on your description it sounds like a regression. Please open a separate bug report, this one already exists for more than a year. Also please add me and the author of the patch as CC.
https://bugs.winehq.org/show_bug.cgi?id=34348
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #20 from Erich Hoover erich.e.hoover@gmail.com --- (In reply to Adam Bolte from comment #18)
... Reverting commit 8e9e4a657f29ff018c6296ced1f115ca8731e5e6 allows the game to run again.
Could you please open a new bug and add me to the CC list?
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #21 from Adam Bolte abolte@systemsaviour.com --- Done and done. For everyone else, it's bug 37966.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #22 from Sebastian Lackner sebastian@fds-team.de --- Thanks to Adam Bolte for providing a download link to the demo of Overlord 2, which can be used to reproduce this problem: http://www.fileplanet.com/200489/200000/fileinfo/Overlord-2-Demo
More affected games are mentioned in * https://bugs.winehq.org/show_bug.cgi?id=37966 * https://bugs.winehq.org/show_bug.cgi?id=11558 (<- the same issue was mentioned there in 2010!)
It works fine with xrandr 1.2, but crashes with xrandr 1.0. For those that normally have a working xrandr 1.2 setup, you can also reproduce the failure by changing the Wine source, and manually setting only_one_resolution = 1 in dlls/winex11.drv/xrandr.c.
Output from my system: --- snip --- trace:xrandr:xrandr12_init_modes Adding mode 0x27f: 1920x1080@60. trace:xrandr:xrandr12_init_modes Adding mode 0x280: 1680x1050@60. trace:xrandr:xrandr12_init_modes Adding mode 0x281: 1440x900@75. trace:xrandr:xrandr12_init_modes Adding mode 0x282: 1440x900@60. trace:xrandr:xrandr12_init_modes Adding mode 0x283: 1280x1024@75. trace:xrandr:xrandr12_init_modes Adding mode 0x284: 1280x1024@60. trace:xrandr:xrandr12_init_modes Adding mode 0x285: 1024x768@75. trace:xrandr:xrandr12_init_modes Adding mode 0x286: 1024x768@60. trace:xrandr:xrandr12_init_modes Adding mode 0x287: 800x600@75. trace:xrandr:xrandr12_init_modes Adding mode 0x288: 800x600@60. trace:xrandr:xrandr12_init_modes Adding mode 0x289: 640x480@75. trace:xrandr:xrandr12_init_modes Adding mode 0x28a: 640x480@73. trace:xrandr:xrandr12_init_modes Adding mode 0x28b: 640x480@60. err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. trace:xrandr:xrandr10_init_modes XRandR: found 10 sizes. trace:xrandr:xrandr10_init_modes - at 0: 1920x1080 (1 rates): 50 Hz trace:xrandr:xrandr10_init_modes - at 1: 1680x1050 (1 rates): 51 Hz trace:xrandr:xrandr10_init_modes - at 2: 1440x900 (2 rates): 52, 53 Hz trace:xrandr:xrandr10_init_modes - at 3: 1280x1024 (2 rates): 54, 55 Hz trace:xrandr:xrandr10_init_modes - at 4: 1024x768 (2 rates): 56, 57 Hz trace:xrandr:xrandr10_init_modes - at 5: 800x600 (2 rates): 58, 59 Hz trace:xrandr:xrandr10_init_modes - at 6: 640x480 (3 rates): 60, 61, 62 Hz trace:xrandr:xrandr10_init_modes - at 7: 1366x768 (1 rates): 63 Hz trace:xrandr:xrandr10_init_modes - at 8: 1280x800 (1 rates): 64 Hz trace:xrandr:xrandr10_init_modes - at 9: 1280x720 (1 rates): 65 Hz --- snip ---
As you can easily see the resolution of the modes do not match. After some searching I found the reason, its a pretty stupid idea from NVIDIA: http://http.download.nvidia.com/XFree86/Linux-x86/1.0-9625/README/chapter-04...
--- quote --- Why is the refresh rate not reported correctly by utilities that use the XRandR X extension (e.g., the GNOME "Screen Resolution Preferences" panel, `xrandr -q`, etc)?
The XRandR X extension is not presently aware of multiple display devices on a single X screen; it only sees the MetaMode bounding box, which may contain one or more actual modes. This means that if multiple MetaModes have the same bounding box, XRandR will not be able to distinguish between them.
In order to support DynamicTwinView, the NVIDIA X driver must make each MetaMode appear to be unique to XRandR. Presently, the NVIDIA X driver accomplishes this by using the refresh rate as a unique identifier.
You can use `nvidia-settings -q RefreshRate` to query the actual refresh rate on each display device.
This behavior can be disabled by setting the X configuration option "DynamicTwinView" to FALSE. --- quote ---
When using an NVIDIA driver (without DynamicTwinView manually disabled), the refresh rates which are passed to the application are not really refresh rates. They are just unique identifiers, and this is what breaks (at least) Overlord 2. Returning fake refresh rates solves it:
--- snip --- diff --git a/dlls/winex11.drv/xrandr.c b/dlls/winex11.drv/xrandr.c index 58e66d6..8d8528c 100644 --- a/dlls/winex11.drv/xrandr.c +++ b/dlls/winex11.drv/xrandr.c @@ -252,6 +252,7 @@ static void xrandr10_init_modes(void) { for (j = 0; j < rates_count; ++j) { + rates[j] = 60; /* HACK */ X11DRV_Settings_AddOneMode( sizes[i].width, sizes[i].height, 0, rates[j] ); xrandr10_modes[xrandr_mode_count++] = i; } --- snip ---
I would guess that the easiest workaround for this bug is to disable DynamicTwinView. I'll check if there is a better solution to solve this, because its of course a bit unfortunate that it doesn't work out of the box. I'll attach a patch if I can come up with some good idea.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #23 from Henri Verbeet hverbeet@gmail.com --- (In reply to Sebastian Lackner from comment #22)
As you can easily see the resolution of the modes do not match. After some searching I found the reason, its a pretty stupid idea from NVIDIA: http://http.download.nvidia.com/XFree86/Linux-x86/1.0-9625/README/chapter-04. html
That's a fairly well known and long standing issue with the NVIDIA drivers (e.g. https://bugs.winehq.org/show_bug.cgi?id=10978#c2 already mentions it), and unfortunately just one of the ways in which NVIDIA RandR support is broken.
From the comments on this bug I have the impression that it's about a different
issue, but it's not always easy to tell.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #24 from Sebastian Lackner sebastian@fds-team.de --- I have heard about it a long time ago, but it isn't really the first thing which comes to my mind when I see the xrandr 1.0 FIXME in one of the logs. Having it somewhere mentioned in (closed) bug reports from 2007 doesn't really help users which encounter this problem, thats why I documented everything here again.
You are right that its difficult to tell if the initial problem is really exactly the same issue, but instead of opening various new bug reports I will just assume that it is identical or at least similar. The description "This prevents most applications from even running at all" also matches what Adam reported when he encountered this problem after commit 8e9e4a657f29ff018c6296ced1f115ca8731e5e6.
Other projects like MythTV seem to include a workaround to query the real refresh using Nvidia extensions. I know that this is a bit ugly, but might be the easiest solution to ensure that wine works out of the box for such setups: https://code.mythtv.org/doxygen/util-nvctrl_8cpp_source.html#l00082
The alternative might be to show at least a winediag message, mentioning that DynamicTwinView is enabled, and that this can cause problems for various games. Just checking if all rates are increasing numbers starting from 50 should be sufficient.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #25 from Rosanne DiMesio dimesio@earthlink.net --- (In reply to Sebastian Lackner from comment #24)
The alternative might be to show at least a winediag message, mentioning that DynamicTwinView is enabled, and that this can cause problems for various games.
That would definitely be better than the current message. Not a single user has ever reported that the nouveau driver solved their problem; what they report is that it makes things much worse.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #26 from Adam Bolte abolte@systemsaviour.com --- Thanks Sebastian for the great analysis. This is the first I've heard of any of this.
I note the documentation you linked (version 1.0-9625) looked to be quite old. This post has driver version information: https://devtalk.nvidia.com/default/topic/533434/linux/current-graphics-drive...
which states:
"Legacy releases for GeForce 2 through GeForce 4 series GPUs (*) Current official release: 96.43.23 (x86 / x86_64) (*) These releases are no longer being maintained."
So that documentation is many years out of date and no longer applies. The documentation for the latest stable version is here: http://us.download.nvidia.com/XFree86/Linux-x86_64/346.35/README/index.html
The reason for mentioning all of this is because there does not appear to be any way to disable TwinView in the current drivers. There is no mention off how to correct the refresh rate on current releases. I have tried various xorg.conf settings to disable it anyway, to no avail.
From this post:
https://devtalk.nvidia.com/default/topic/548763/?comment=3872874 It further confirms that this option has been removed. So it looks like we'll need to implement a work-around if we ever want this to work under modern Nvidia hardware.
On a different note, since we're back to this bug ID, I would also like to point out that the "Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead." message really needs to be removed. According to: http://www.phoronix.com/scan.php?page=news_item&px=Wine-D3D9-Gallium-Nin... Stefan Dösinger explained that he does not believe Gallium3D D3D9 is an option for Wine, and as part of his reasoning for this he basically explained Mesa is too slow (see points 2 and 4), and implied the Nvidia driver is the best option for performance right now (in point 3). I don't know if I agree or disagree with rejecting the D3D9 patches, and I certainly don't want to start a debate about that here, but having a message in Wine saying you should not use the "broken" Nvidia drivers appears very contradictory to some of the recent statements that came out of FOSDEM. :)
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #27 from Henri Verbeet hverbeet@gmail.com --- (In reply to Adam Bolte from comment #26)
On a different note, since we're back to this bug ID, I would also like to point out that the "Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead." message really needs to be removed. According to: http://www.phoronix.com/scan.php?page=news_item&px=Wine-D3D9-Gallium-Nin... Opposed Stefan Dösinger explained that he does not believe Gallium3D D3D9 is an option for Wine, and as part of his reasoning for this he basically explained Mesa is too slow (see points 2 and 4), and implied the Nvidia driver is the best option for performance right now (in point 3).
Well, no. The proprietary NVIDIA driver generally has better performance than Mesa, but for many things Nouveau is perfectly adequate, and it would be a pretty sad world in which performance would be the only consideration for which software to use. I also think there's a significant difference between asking someone to consider an option and telling them not to do something.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #28 from Adam Bolte abolte@systemsaviour.com ---
Well, no. The proprietary NVIDIA driver generally has better performance than Mesa, but for many things Nouveau is perfectly adequate, and it would be a pretty sad world in which performance would be the only consideration for which software to use. I also think there's a significant difference between asking someone to consider an option and telling them not to do something.
I do agree with those points too. I would imagine that driver software being "free software" should be an important consideration, for example. On that point, it seems to me that including D3D9 would have probably helped a lot of people move away from proprietary drivers and onto the free drivers. However, I didn't really want to get into a discussion of the pros and cons of the chosen approach here. :)
And you are correct that the output does say "consider". But it feels far more forceful than that when it's constantly filling up your screen with those warnings. ie:
abolte@ettin:~$ wine cmd.exe wine: created the configuration directory '/home/abolte/.wine' err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. fixme:ntdll:NtLockFile I/O completion on lock not implemented yet err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:mscoree:LoadLibraryShim error reading registry key for installroot err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:iphlpapi:NotifyAddrChange (Handle 0x195e1a8, overlapped 0x195e1c0): stub err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:iphlpapi:NotifyAddrChange (Handle 0x166e820, overlapped 0x166e82c): stub err:winediag:xrandr12_init_modes Broken NVIDIA RandR detected, falling back to RandR 1.0. Please consider using the Nouveau driver instead. wine: configuration in '/home/abolte/.wine' has been updated. Microsoft Windows 5.2.3790 (1.7.35)
Z:\home\abolte>
So that's only a built-in command line application. Instead, maybe we could just complain about it the one time when Wine first needs to use RandR? The current vibe I get when I see that is "Something is broken and you need to take action to fix this or otherwise there will be uncertain consequences and don't say you weren't warned!".
Is there anything Wine needs to do that RandR 1.0 cannot? Searching for RandR on the Wine wiki returns 0 results.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #29 from Henri Verbeet hverbeet@gmail.com --- (In reply to Adam Bolte from comment #28)
So that's only a built-in command line application. Instead, maybe we could just complain about it the one time when Wine first needs to use RandR?
Yes, that's unfortunate, but not something we can easily fix. The message is actually only printed once when winex11.drv is loaded, but this happens for each process that loads winex11.drv.
Is there anything Wine needs to do that RandR 1.0 cannot? Searching for RandR on the Wine wiki returns 0 results.
The most significant things RandR 1.3 gets you are RRGetScreenResourcesCurrent to query the current configuration without polling the display connectors, and the ability to set the display mode independently on different displays of a multihead setup. (I.e., changing the display mode of one display without either the other displays going black or the contents getting stretched over all displays.) Note though that even the RandR 1.0 implementation in the proprietary NVIDIA drivers has its own issues.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #30 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Henri Verbeet from comment #27)
Well, no. The proprietary NVIDIA driver generally has better performance than Mesa, but for many things Nouveau is perfectly adequate
As a person with NVidia hardware and a need to regularly run 'make test' for the whole Wine tree including ddraw/d3d* directories I'd say that Nouveau is very far from being adequate even with latest Linux kernels. Disabling a bunch of directories just to avoid constant crashes inside of Nouveau can't be adequate, not mentioning that running a moderate, not d3d centric application with some translucency/layered windows makes the whole system sluggish and forces the video card fun constantly rotate. Nouveau may be adequate for a simple set of office applications, but that's it.
Sorry for off-topic, but that's really a pain to work with such a PoS.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #31 from Adam Bolte abolte@systemsaviour.com --- Thanks for the detailed explanation Henri.
In that case, how about a registry setting the user can add to disable the warning? That way, at least we know they have seen it.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #32 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Adam Bolte from comment #31)
Thanks for the detailed explanation Henri.
In that case, how about a registry setting the user can add to disable the warning? That way, at least we know they have seen it.
No registry key is necessary, there is no technical limitation to show the message just once. I'll write a patch later. But the discussion about the warning itself should probably be moved to a separate bug report. Feel free to add me as CC if you're going to open one.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #33 from Adam Bolte abolte@systemsaviour.com --- (In reply to Sebastian Lackner from comment #32)
No registry key is necessary, there is no technical limitation to show the message just once. I'll write a patch later. But the discussion about the warning itself should probably be moved to a separate bug report. Feel free to add me as CC if you're going to open one.
Thanks! Opened bug #38032 and CCed you.
https://bugs.winehq.org/show_bug.cgi?id=34348
Aaron Plattner aplattner@nvidia.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aplattner@nvidia.com
--- Comment #34 from Aaron Plattner aplattner@nvidia.com --- Just in case it's gotten lost over the years, I wanted to reiterate that the correct fix for this is for Wine to use RandR 1.2's transforms to achieve the scaling it wants rather than hoping the monitor has the timings it expects, or relying on RandR 1.1's implicit scaling.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #35 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Aaron Plattner from comment #34)
Just in case it's gotten lost over the years, I wanted to reiterate that the correct fix for this is for Wine to use RandR 1.2's transforms to achieve the scaling it wants rather than hoping the monitor has the timings it expects, or relying on RandR 1.1's implicit scaling.
Wine supports RandR 1.2 of course, but can't use it in some cases. The main reason why some people are still forced to use RandR 1.0 is:
--- snip --- /* Recent (304.64, possibly earlier) versions of the nvidia driver only * report a DFP's native mode through RandR 1.2 / 1.3. Standard DMT modes * are only listed through RandR 1.0 / 1.1. This is completely useless, * but NVIDIA considers this a feature, so it's unlikely to change. The * best we can do is to fall back to RandR 1.0 and encourage users to * consider more cooperative driver vendors when we detect such a * configuration. */ if (only_one_resolution && XQueryExtension( gdi_display, "NV-CONTROL", &i, &j, &ret )) { ERR_(winediag)("Broken NVIDIA RandR detected, falling back to RandR 1.0. " "Please consider using the Nouveau driver instead.\n"); --- snip --- ( see http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/xrandr.c#l... )
Based on your email address I assume you know the reason why NVIDIA decided to implement it that way. Do you have any better idea how to solve it, without falling back to RandR 1.0? The wined3d developers might know better, but I would guess that some Windows applications are not really happy when they have only one resolution to choose from ...
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #36 from Aaron Plattner aplattner@nvidia.com --- Unlike older systems, when RandR 1.2 refers to a "mode", it's referring to the actual timings being sent to the monitor. For Wine's purposes, those are largely irrelevant (aside from the refresh rate) since all that really matters to the applications running inside are the height and width of the framebuffer. RandR 1.2 has a transform mechanism that allows applications to scale an arbitrary region of the framebuffer to fill the screen, so Wine can make up whatever list of resolutions it wants and scale them to the display's native resolution. For example, if an application requests an 800x600 screen size, then rather than relying on sending actual 800x600 timings to the monitor, you can just scale an 800x600 desktop to the display's native resolution.
The point is that RandR 1.2 puts this control into the hands of X clients like Wine. What they choose to do with it is up to them.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #37 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Aaron Plattner from comment #36)
... For example, if an application requests an 800x600 screen size, then rather than relying on sending actual 800x600 timings to the monitor, you can just scale an 800x600 desktop to the display's native resolution.
So, should we report only resolutions that are smaller than the actual display size or should we just use a complete list of reasonable resolutions? I assume that we should report the real refresh rate of the monitor for all the resolutions we report.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #38 from Aaron Plattner aplattner@nvidia.com --- At least on NVIDIA hardware you can downscale from a larger resolution to a smaller one, but it doesn't always look great and it might be confusing for users. I'd recommend making it an option that's disabled by default.
For the refresh rate, just reporting the monitor's native refresh rate for all available modes would be a good first start. If you like, you can try to do something fancier like choosing the largest mode that matches the target refresh rate if multiple are available, and using the availability of particular refresh rates to choose which refresh rates to report to the Windows side.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #39 from Erich E. Hoover erich.e.hoover@wine-staging.com --- Created attachment 51757 --> https://bugs.winehq.org/attachment.cgi?id=51757 winex11.drv: Add support for legacy resolutions using XRandR 1.3 affine transforms.
(In reply to Aaron Plattner from comment #36)
... RandR 1.2 has a transform mechanism that allows applications to scale an arbitrary region of the framebuffer to fill the screen, so Wine can make up whatever list of resolutions it wants and scale them to the display's native resolution. ...
Hi Aaron, thanks for the advice. I've put together a patch that does this using XRRSetScreenSize and XRRSetCrtcTransform and it finally doesn't cause my X server to crash ;) The way I'm doing this currently is using the matrix: dw/nw 0 0 0 dh/nh 0 0 0 1 where dw = desired width, dh = desired height, nw = native width, nh = native height
This makes the entire screen filled with the requested screen resolution (stretched), which should be good enough for now. However, I like the aspect-ratio maintaining behavior that nvidia-settings does when you use scaled resolutions like this. Is there an easy way for me to maintain the aspect ratio and have black bars on the sides instead?
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #40 from Aaron Plattner aplattner@nvidia.com --- You can do it with the Border property I added: http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt#n2029
It's not completely straightforward because it's designed to be able to handle hardware that can only adjust all four sides at once, or which can only adjust top/bottom and left/right together. So see the description of BorderDimensions and what happens if you only set 1 or 2 entries instead of all 4.
In practice, I think the nvidia driver is the only one that actually implements it and we support BorderDimensions=4, so you can set whatever borders you like. Border is like the transform in that it has a pending value and a current value, so you basically just set the pending value and then it gets latched during SetCrtcConfig.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #41 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to Erich E. Hoover from comment #39)
Is there an easy way for me to maintain the aspect ratio and have black bars on the sides instead?
What happens if you simply use min(dw/nw, dh/nh) for both the (1,1) and (2,2) matrix elements? Assuming you can do that, I know nothing about Xrandr (and sorry if that's a dumb suggestion).
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #42 from Erich E. Hoover erich.e.hoover@wine-staging.com --- (In reply to Matteo Bruni from comment #41)
... What happens if you simply use min(dw/nw, dh/nh) for both the (1,1) and (2,2) matrix elements? Assuming you can do that, I know nothing about Xrandr (and sorry if that's a dumb suggestion).
That doesn't work ;) I'll look into the "Border" property when I have some time, a quick test with xrandr ended up having panning enabled for the resulting centered desktop: xrandr --verbose --output LVDS-0 --scale-from 1280x1024 --set "Border" "285, 0, 285, 0" ^^ for my native resolution of 1920x1080
However, if you have a system affected by this bug I'd love additional testers :)
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #43 from Erich E. Hoover erich.e.hoover@wine-staging.com --- Ok, I've now obtained the desired functionality with XRandR: xrandr --verbose --output LVDS-0 --transform "0.948148,0,0,0,0.948148,0,0,0,1" --set "Border" "285, 0, 285, 0" --fb "1280x1024" This properly generates a centered 1280x1024 screen with maintained aspect ratio on a 1920x1080 display. I'll hopefully have a chance to put this into code-form soon, but this should do the trick and allow us to have much better support for legacy resolutions. Many thanks to Aaron for pointing me in the right direction :)
https://bugs.winehq.org/show_bug.cgi?id=34348
Franz Rupnow rup1033@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rup1033@gmail.com
--- Comment #44 from Franz Rupnow rup1033@gmail.com --- I also get the xrandr 1.0 error fallback with wine staging 2.7. But I am using Legacy Nvidia drivers 340.102 with a Quadro FX2800M on a Lenovo laptop. Most applications work though. Only one does not work and I plan to make a seperate bug report for that. But the application which does not launch for me is Valkyria Chronicles and it not launching does not seem to be related to XrandR. Though the warnings still pop up saying it reverts to 1.0. For now just compile with --without-xrandr and the warning will go away. I tested with Nouveau and Valkyria Chronicles loads. So its definately some issue that is with Legacy only nvidia drivers.
https://bugs.winehq.org/show_bug.cgi?id=34348
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |titan.costa@gmail.com
--- Comment #45 from Zhiyi Zhang zzhang@codeweavers.com --- *** Bug 50479 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=34348
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |b1779506@trbvn.com
--- Comment #46 from Zhiyi Zhang zzhang@codeweavers.com --- *** Bug 51253 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=34348
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #47 from Otto b1779506@trbvn.com --- Still happening with wine-6.11 (Staging)
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #48 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Otto from comment #47)
Still happening with wine-6.11 (Staging)
Have you tried enabling the staging patchset for fixing this? It's disabled by default, but if it works for you then I can update it and fix the issue with it (symbols are not dynamically loaded, so it currently requires the nvidia library for everyone): https://github.com/wine-staging/wine-staging/tree/master/patches/winex11-Lim...
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #49 from Otto b1779506@trbvn.com --- (In reply to Erich E. Hoover from comment #48)
Have you tried enabling the staging patchset for fixing this? It's disabled by default, but if it works for you then I can update it and fix the issue with it (symbols are not dynamically loaded, so it currently requires the nvidia library for everyone): https://github.com/wine-staging/wine-staging/tree/master/patches/winex11- Limited_Resolutions
No I haven't, I'm running ubuntu packages. Do you want me to recompile wine with that patch?
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #50 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Otto from comment #49)
... No I haven't, I'm running ubuntu packages. Do you want me to recompile wine with that patch?
If you have the chance to do so, it would be very helpful.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #51 from Otto b1779506@trbvn.com --- Can you please provide a patch to apply on latest git source code (git clone git://source.winehq.org/git/wine.git)? I can't find entry point 'static void xrandr10_init_modes(void)' on 'wine/dlls/winex11.drv/xrandr.c'
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #52 from Otto b1779506@trbvn.com --- Still not fixed in wine-6.14 (Staging). Maximum refresh rate 50Hz.
https://bugs.winehq.org/show_bug.cgi?id=34348
Frederick Zhang frederick888@tsundere.moe changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederick888@tsundere.moe
https://bugs.winehq.org/show_bug.cgi?id=34348
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
--- Comment #53 from mirh mirh@protonmail.ch --- (In reply to Erich E. Hoover from comment #39)
Created attachment 51757 [details] winex11.drv: Add support for legacy resolutions using XRandR 1.3 affine transforms.
Did anything go any further with this patch?
Also, isn't libXNVCtrl/nvidia-settings licensed with GPL2? What kind of concern would have prompted staging to disable the limited resolutions patch for a decade?
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #54 from Zhiyi Zhang zzhang@codeweavers.com --- (In reply to mirh from comment #53)
(In reply to Erich E. Hoover from comment #39)
Created attachment 51757 [details] winex11.drv: Add support for legacy resolutions using XRandR 1.3 affine transforms.
Did anything go any further with this patch?
Yes, using transforms to provide legacy resolutions when there is only the native resolution looks like the right way to go. Please submit it upstream whenever you think it's ready.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #55 from Aaron Plattner aplattner@nvidia.com --- You shouldn't need libXNVCtrl for this, it's core RandR protocol. But for what it's worth, while the nvidia-settings app as a whole is GPL, the libXNVCtrl library it uses has an MIT license. See the license comment at the top of https://github.com/NVIDIA/nvidia-settings/blob/main/src/libXNVCtrl/NVCtrl.c
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #56 from mirh mirh@protonmail.ch --- Yes, the transforms are core RandR (and I'm just nobody, so somebody should step up to update compholio's work).
But then there's the other "limited resolutions" patch in staging too (which despite the name is supposedly about wrong refresh rates with TwinView enabled) that was disabled in 2015 for both licensing and dependency linking worries. Go figure.
https://bugs.winehq.org/show_bug.cgi?id=34348
--- Comment #57 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to mirh from comment #56)
Yes, the transforms are core RandR (and I'm just nobody, so somebody should step up to update compholio's work).
But then there's the other "limited resolutions" patch in staging too (which despite the name is supposedly about wrong refresh rates with TwinView enabled) that was disabled in 2015 for both licensing and dependency linking worries. Go figure.
IIRC, you want to do something more like attachment 51757 (transforms) and less like the staging patchset (fetching the legacy modes). The transforms do not require any special nvidia-specific library calls, though it's perfectly fine to do that if you need them. The laptop I have now is not impacted by this issue, so I no longer have a good way to test this and confirm that it's doing what it's supposed to.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla