https://bugs.winehq.org/show_bug.cgi?id=51420
--- Comment #49 from Sveinar Søpler cybermax@dexter.no --- (In reply to Henri Verbeet from comment #48)
(In reply to Sveinar Søpler from comment #45)
(In reply to Henri Verbeet from comment #44)
Of course it would be even better if the NVIDIA drivers would synthesise the standard display modes when using RandR 1.4+ on configurations like this, like pretty much all the other Linux GPU drivers do, but I'm not holding my breath.
Is this a particular DVI-D problem, and does not rear its ugly head with HDMI or DP configurations, or should i see the same issue there?
My understanding is that it largely depends on whether the display in question has its own (hardware) scaler, or depends on the GPU for that. In the past, that largely correlated with whether the display was internal or external. Internal (typically LVDS) displays in e.g. laptops typically didn't have scaler hardware, while external monitors connected by VGA or DVI typically did. It's a little less straightforward with modern external displays that may not support VGA/DVI-I.
(Note incidentally that DVI-I is essentially the same as VGA, and DVI-D is essentially the same as HDMI; converters between these are typically passive.)
@mitchell4136 I have been looking a bit into this with the nVidia driver + xorg, and it is quite a few caveats the nvidia driver checks for during the init. I added this to my xorg.conf under the "Device" section:
Option "ModeDebug" "True"
This will print all modes the driver tries to check during init (bootup or possibly restart of x11), and can be viewed in the log /var/log/Xorg.0.log . For my monitor it actually said it was some checksum error with the monitors EDID "extended information" (or something like that), and it COULD explain why i do not have as many resolution options on my 1440p monitor as my old 1080p 2nd monitor.
Anyway, if you do that, you should be able to see if or why the driver will not "approve" of certain resolutions. It could be a number of things - one of them being somewhat of a broken EDID, or it could be that the monitor actually does not HAVE any internal upscaling/support for that resolution and rightfully reports (to the driver) that it only supports one mode. Need to check logs for that tho.
One thing to try could be (still under the "Device" section of xorg.conf):
Option "ModeValidation" "NoEdidModes"
and then add modes manually via the options:
Option "MetaModes" "1280x1024,1280x1024; 1024x768,1024x768" Option "MetaModes" "1280x1024,1024x768; 1280x2024,800x600"
and so on. This would build modes manually, and is not directly self explanatory i guess. There is also the option to specify connected ports and whatnot for these options.
This is documented quite a bit here: https://download.nvidia.com/XFree86/Linux-x86_64/100.14.23/README/appendix-b... https://download.nvidia.com/XFree86/Linux-x86_64/100.14.23/README/chapter-13...
@Henri What i suspect the nouvau driver does is just use a much more leanient check of these "EDID readings" or whatever safetychecks the driver does natively, and just automaticall "add modes" similar to what i describe above, and THAT is why it works "better" with that driver. It does not mean it is the right thing to do, nor that it is the safe thing to do, even tho it may work most of the time. I think the nVidia driver tries it best to detect - within margins of capabilities reported - the correct settings, and sometimes gets it wrong for various reasons (bugged EDID as an example). I had quite a few modes on my 1440p monitor that was "not valid" due to it not existing in the EDID. If that is because the EDID has some errors in it, it is not nVidia's fault. I also checked my monitors EDID on http://www.edidreader.com/ and it showed the same errors there.
The wine workaround in the case of "only one resolution detected" is mostly working fine, but it might not be the REAL cause of the problems. As far as i can tell ASUS claims my 1440p monitor can support 1920x1080@120Hz, but from the debug log and xrandr it does not. Is it one of these "extended modes" with the wrong checksum, or is it a driver bug? I will do some more testing.
PS. It is not the first (or last) time that Asus is a bit slacking with their BIOS or EDID things.. Eg. there are loads of UEFI errors detected by the Linux kernel on many Asus UEFI bios', that Windows happily ignores, but require kernel patches or boot option overrides for linux - and Asus just brush it off with "Linux is not supported - wontfix". I guess other manufacturers are not THAT much better, and we all know what the Linux community thinks of "quirks and workarounds" in the case of manufacturer errors that they usually get away with in windows.....