http://bugs.winehq.org/show_bug.cgi?id=30154
--- Comment #20 from Dmitry Timoshkov dmitry@baikal.ru 2012-03-15 23:17:10 CDT --- (In reply to comment #19)
I don't think anyone denied there was a driver/hardware bug involved as well. But that doesn't change the fact that the way XRandR is currently used in Wine causes completely unnecessary EDID polls.
(1)
- wine is requesting the information again and again
Calls to EnumDisplaySettings*() with ENUM_CURRENT_SETTINGS do this.
- and is forcing xrandr to do a reprobe instead of just getting the current
information.
Just about any XRandR 1.2 query will do this.
(2)
Aren't (1) and (2) assume that Wine has nothing to do with broken xrandr implementations?
The way to fix it is to use XRandR 1.3 RRGetScreenResourcesCurrent for querying, and e.g. RRScreenChangeNotify events to get notified of configuration changes. This is practically needed for proper multi-head support anyway, and listening for the appropriate events will also fix the issue where applications are unaware of mode changes by other applications.
The fact that setting UseXRandR to "N" in the registry makes the problem go away, and that you think that using xrandr 1.3 will avoid the bug suggests that video driver is able to behave sanely. Why underlying behaviour of the driver is so drastically different, and what Wine has to do with it is left as an exercise for the reader.