At the risk of making a review comment before fully understanding the problem myself, do we actually need to be passing all the dimensions? We even have a D3DKMT device handle we could be passing. Though this is bikeshedding, which isn't really warranted at this point.
D3DKMT device only map to a GPU, not really to a monitor. In any case, I don't think going through a proper D3DKMT route is feasible right now, we're missing too much infrastructure and I'm not even sure we want to bypass the host WSI completely (which a D3DKMTPresent would probably need to do). Passing the full present rectangle to win32u helps it decide how to map the window surface onto the screen, there's additional issues on the win32u side related to display mode emulation, that need to be handled properly, and having a full rect helps I think.
However, I think the right thing to do is to make this call from wined3d_swapchain_state_setup_fullscreen() and wined3d_swapchain_state_restore_from_fullscreen(), rather than their callers.
I don't think so, `wined3d_swapchain_state_setup_fullscreen` is only called once when entering fullscreen and not when fullscreen mode changes. We need to update the present rect in that case as well, so win32u can keep the window fullscreen.
Wait, I'm confused. win-\>present_rect isn't used anywhere. Are we missing some changes here?
Yes, like I said only introduces the mechanism and uses it from wined3d. I wanted to keep things simple to make it easier to review the client side API. Implementing the bits on win32u / winex11 is fairly straightforward after that. I've pushed the additional changes to https://gitlab.winehq.org/rbernon/wine/-/commits/mr/9585. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9585#note_124517