[PATCH 1/1] wined3d: Don't take the wined3d mutex during WM_DISPLAYCHANGE either.

[Henri Verbeet]

While changing the display mode itself can handle us waiting on the wined3d
mutex just fine, this would also block subsequent messages from being
processed. In particular, a call to wined3d_device_reset() immediately
following a wined3d_set_display_mode() call may deadlock on e.g. the
MoveWindow() call in wined3d_device_reset(). Just dropping the locking here is
probably the right thing to do. The device_parent->ops pointer should always
be valid since it's set on device creation and never changed until the device
is destroyed, and device_process_message() is only ever called for valid
devices. Dropping the locking does mean that mode_changed() implementations
have to be a bit more careful about what they can and can't do though.

This is for bug 29919.
---
 dlls/ddraw/ddraw.c    |    2 ++
 dlls/wined3d/device.c |    2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c
index 99c0a69..25519d2 100644
--- a/dlls/ddraw/ddraw.c
+++ b/dlls/ddraw/ddraw.c
@@ -5359,6 +5359,8 @@ static void CDECL device_parent_wined3d_device_created(struct wined3d_device_par
     TRACE("device_parent %p, device %p.\n", device_parent, device);
 }
 
+/* This is run from device_process_message() in wined3d, we can't take the
+ * wined3d mutex. */
 static void CDECL device_parent_mode_changed(struct wined3d_device_parent *device_parent)
 {
     struct IDirectDrawImpl *ddraw = ddraw_from_device_parent(device_parent);
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index d0768aa..17560c6 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -5912,9 +5912,7 @@ LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL
     }
     else if (message == WM_DISPLAYCHANGE)
     {
-        wined3d_mutex_lock();
         device->device_parent->ops->mode_changed(device->device_parent);
-        wined3d_mutex_unlock();
     }
 
     if (unicode)
-- 
1.7.3.4