This is especially important for M1 GPUs as they don't support the 24/8 format.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of after sending the WM_MACDRV_UPDATE_DESKTOP_RECT
message. Specifically ddraw reacts to the followup messages and
expects to get the new display rects inside the message handler.
Signed-off-by: Matteo Bruni <mbruni@codeweavers.com>
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes GPU detection when running in VMware Fusion, where the GPU entry
lacks a "model" property.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49774
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
EnumDisplaySettings() on Wine does not write beyond the end of DEVMODE because it doesn't use
dmDriverExtra currently, but this implementation detail should not be relied on.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
0 or 1 in dmDisplayFrequency means to use the default frequency.
Fix Disgaea PC and Ostriv failing to launch in exclusive fullscreen mode.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Set DM_POSITION and DM_DISPLAYORIENTATION when calling
EnumDisplaySettings(ENUM_REGISTRY_SETTINGS). DM_DISPLAYFIXEDOUTPUT
is not set because it is not necessarily reported according to tests.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It is currently unsupported. This helps later patches so that
settings handlers using a new interface can be introduced without
detaching adapter support, making patches smaller.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Changing non-primary adapter settings is currently unsupported. Return
success for non-primary adapter settings changes so that the primary
adapter settings don't get changed unintentionally.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
NULL device and mode parameters mean to restore all adapters to their
registry settings. Since all user graphics drivers only support a
primary adapter now, it's okay to restore only the primary adapter.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently, there is a race condition where if two threads call into
OpenGL at the same time, one of them will initialize OpenGL, but the
other will barrel on ahead, thinking GL is already initialized, even
though the first thread hasn't finished initializing it yet. One of the
symptoms of this is that no pixel formats appear to be available,
because the first thread hasn't yet enumerated the available pixel
formats.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Prefer it to VK_MVK_macos_surface when present.
MoltenVK has deprecated VK_MVK_macos_surface in favor of
VK_EXT_metal_surface. It's likely that the former extension will vanish
at some point.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It isn't safe to access the view object from any thread other than the
main thread. In fact, if you try to call vkCreateMacOSSurfaceMVK() from
any other thread, MoltenVK prints out a big, scary warning telling you
not to do this! Instead, get the layer from the view ourselves and pass
that to MoltenVK. Recent versions of MoltenVK can accept either the view
or the layer.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
I was seeing a crash due to an assert about manipulating it on a
background thread. I can't recall where I was seeing that. I think it's
new in Catalina.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We rely on AppKit-internal events to know when a window is being
dragged. In Catalina, AppKit stopped sending the "drag ended" event when
no drag actually took place, though it still sends "drag started" events
when the title bar is clicked. Ironically, this caused us to think the
window was still being dragged. In that case, waiting for the mouse
button to come back up should allow us to determine when the drag should
end.
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
miniaturize fails to minimize window when NSMiniaturizableWindowMask
style is not set. The style will be restored on window restore (or earlier).
Signed-off-by: Piotr Caban <piotr@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
D3DKMTSetVidPnSourceOwner needs to be implemented in the graphics drivers
because we need to maintain the VidPN source ownership information list
in the graphics drivers. For example, the graphics drivers need to release the
exclusive ownership when a new window is moved to a monitor which has been taken
exclusive ownership.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>