http://bugs.winehq.org/show_bug.cgi?id=30154
--- Comment #19 from Henri Verbeet hverbeet@gmail.com 2012-03-15 19:23:09 CDT --- (In reply to comment #18)
Wine is a user level application, it's by definition a kernel/vidoe driver bug if doing a simple video modes query (just once at start up!) makes X block for several seconds.
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.
This doesn't happen just once on startup either. As the linked source shows, calling XRRGetScreenInfo() causes a poll. X11DRV_XRandR_GetCurrentMode() calls XRRGetScreenInfo(). This is what is used to implement the ENUM_CURRENT_SETTINGS part of the EnumDisplaySettings*() calls, and it's certainly not unheard of for applications to call those.
You can certainly argue that this bug isn't a very high priority for Wine, and that it's more important to get the driver fixed so that polls aren't so expensive. You can't argue that Wine doesn't cause these polls.
Wine doesn't do anything of the listed below things as the reporter claims:
- 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. 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.