On Wed Jun 3 10:14:46 2026 +0000, Marc-Aurel Zent wrote:
But we are not depending on any internals structures here, no? The consumer of the API just needs to get a metal layer for its HWND, and this is much better than the usage of get_win_data, create_metal_device, create_metal_view, get_metal_layer, release_win_data, that is currently done by downstream projects (for more recent versions even through a compatibility shim, since Wine internals did change there). The surface pointer is just something opaque the consumer needs to release after it is done with the Metal layer, not something that is used in any other way...
/* ExtEscape definitions */
enum macdrv_escape_codes
{
MACDRV_ESCAPE_GET_SURFACE = 6790,
MACDRV_ESCAPE_RELEASE_SURFACE,
};
struct macdrv_escape_surface
{
UINT64 surface;
UINT64 layer;
};
The above would be the "public" API we can't change, and I can't believe this can be made much simpler... Theoretically, we could store a Metal layer to window surface mapping internally, and the consumer only gets the layer, and then later releases the layer, but I am not too sure a 1:1 mapping is always a given there, since the layer is a weak reference... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11058#note_142091