[Bug 51420] Running any program in Wine causes 100% cpu usage in Xorg

[WineHQ Bugzilla]

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

--- Comment #49 from Sveinar Søpler <cybermax at 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.html
https://download.nvidia.com/XFree86/Linux-x86_64/100.14.23/README/chapter-13.html

@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 at 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.....

-- 
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.