[PATCH 6/6] user32: Implement EnumDisplayDevicesW() based on EnumDisplayMonitors() and GetMonitorInfoW().

Ken Thomases ken at codeweavers.com
Mon Mar 31 13:38:40 CDT 2014

On Mar 31, 2014, at 5:20 AM, Alexandre Julliard wrote:

> Yes, display settings/modes, adding/removing monitors, managing work
> area, restoring resolution on process exit, etc.  There would be parts
> in user32, parts in the driver, but it should all run in the context of
> the explorer process. Normal processes should retrieve the info from
> explorer instead of using graphics driver calls.

That can't work with the Mac driver.

In order to be a good citizen, the Mac driver captures the display before changing the display mode.  As a consequence, only the process which actually changed the mode can display anything until the mode is reset.  Furthermore, the reason for capturing the display is to prevent other processes from receiving notification that the desktop has changed size, so they don't re-layout their windows or, in the case of the Finder, desktop icons.  So, it's not even possible for the explorer to observe the change without the process that made the change telling it directly.

I'm not certain, but I suspect that what you suggest also doesn't match what Direct3D does on Windows.  My impression is that when an app uses D3D to enter exclusive full-screen mode, that other apps aren't informed about the mode change.  (If I'm right, then Wine behaves incorrectly currently.)


More information about the wine-devel mailing list