So that the mf tests pass again on 32bit on the testbot, though they still fail locally with `LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=softpipe`.
--
v5: mf: Uninitialize renderer before creating mixer and presenter.
mf: Release video renderer services before re-initializing.
mf: Avoid leaking nodes in IMFTopoLoader_Load.
mf/tests: Add some missing IMFActivate_Shutdown calls.
mf/tests: Add more consistent reference count checks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/310
So that the mf tests pass again on 32bit on the testbot, though they still fail locally with `LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=softpipe`.
--
v4: mf: Uninitialize renderer before creating mixer and presenter.
mf: Release video renderer services before re-initializing.
mf: Avoid leaking nodes in IMFTopoLoader_Load.
mf/tests: Add some missing IMFActivate_Shutdown calls.
mf/tests: And more consistent reference count checks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/310
> When running under qemu-user CPU emulation, this can mean we not only remove the vdso from the process being launched (a performance degradation), but also clobber it out from under the qemu-user emulator hosting the wine-preloader process - which is in fact in the midst of a call to mmap that is *using* the vdso, so the emulator then segfaults before returning
I'd call a QEMU bug.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6#note_2791
So that the mf tests pass again on 32bit on the testbot, though they still fail locally with `LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=softpipe`.
--
v3: mf: Uninitialize renderer before creating mixer and presenter.
mf: Release video renderer services before re-initializing.
mf: Avoid leaking nodes in IMFTopoLoader_Load.
mf/tests: Add some missing IMFActivate_Shutdown calls.
https://gitlab.winehq.org/wine/wine/-/merge_requests/310
Another interesting case in this same area is qemu-user emulation. As you say, right now wine-preloader just uses MAP_FIXED and removes anything in its way (potentially including the vdso of ASLR put it in the way).
When running under qemu-user CPU emulation, this can mean we not only remove the vdso from the process being launched (a performance degradation), but also clobber it out from under the qemu-user emulator hosting the wine-preloader process - which is in fact in the midst of a call to mmap that is *using* the vdso, so the emulator then segfaults before returning (intermittently, since ASLR doesn't always put the vdso in the way, but often enough I have seen it hit the in[0x7ffffe000000, +0x01ff0000 range](https://gitlab.winehq.org/wine/wine/-/blob/master/loader/preloader.c…
I'm just remapping it won't fix that problem (having it move mid-call is going to be just as fatal as unmapping it), but it potentially makes it more tractable. qemu is already holding some separation/tagging of host vs guest, so maybe it could special case mremap to move it for us but retain it for its own purposes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6#note_2780
Once we reached that place where sync_window_position() is called (or not called if window is about to be minimized or maximized) the old in-flight X_ConfigureNotify do not make sense anymore. sync_window_position() does that unconditionally but if we don't call it for minimize / maximize we should probably discard them regardless.
An example of the failing scenario which this patch is fixing is the following:
1. App calls SetWindowPos() with some size, X_ConfigureNotify is in flight;
2. App calls ShowWindow(SW_MAXIMIZE), old X_ConfigureNotify is still in flight; sync_window_position() is not called and configure_serial is not updated;
3. Now X_ConfigureNotify from p.1 arrives and it gets processed like WM is changing window size back, that confuses the app and since the reaction on the new app's SetWindowPos / maximizing is also delayed and then X events triggered by p. 2. also arribe later. That may cause endless loop with non-functional window.
--
v2: winex11.drv: Increment configure_serial in X11DRV_WindowPosChanged() even if not syncing window position.
https://gitlab.winehq.org/wine/wine/-/merge_requests/312