Thanks, the overall approach looks good (note: I haven't done a detailed review). I like both this and !6107 in different ways, so if this is the direction you prefer, I am happy to move forward with it. I have pushed some potential improvements to https://gitlab.winehq.org/afrantzis/wine/-/commits/wip/wayland-child-surface... (rebased on latest version). Relatedly, I also cleaned up some changes to glmark2, which I have been using to manually test some more exotic nested/reparenting scenarios, and pushed them to https://github.com/glmark2/glmark2/tree/win32-nested (please read https://github.com/glmark2/glmark2/blob/win32-nested/README.win32-nested), in case it's useful for your testing. I have found that on some compositors (e.g. kwin) this MR leads to issues with some of the glmark2 scenarios (whereas !6107 works fine), but I think it's actually the compositor's fault not dealing well with some of the subsurface detachment/attachments in this MR. Experimenting a bit, I found that if we ensure that the client surface does not have an attached buffer before creating a new wl_subsurface for it, then the issues go away, but this shouldn't be needed (Weston works fine for example). FWIW, last time I tried mutter it also didn't behave well with more complex subsurfaces scenarios, so I haven't been using it much for testing these MRs. -- One concern I have is that the Wayland EGL/VK presentation functions perform operations (+final commit) on the target wl_surface (the client surface one in our case). Since GL/VK rendering may be running in arbitrary threads, this sequence interleaved with other commits on that particular wl_surface from other threads (e.g., WindowPosChanged in the window thread). Both !6107 (but only rarely, when we have to change the surface role) and this MR (much more often) introduce such a commit in WindowPosChanged (e.g., client attach/detach). This might have adverse effects (depends on driver internals, the code in Mesa's Vulkan Wayland WSI makes me particularly worried). I am thinking that a possible approach here is to avoid all commits on `client->wl_surface` (i.e., in reconfigure_client) and let all changes be applied when EGL/VK performs the next commit itself. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6323#note_79616