wine-devel

wine-devel@winehq.org

3 participants
84472 discussions

Re: [PATCH v6 0/5] MR310: mf: Fix several reference leaks.
by Rémi Bernon (＠rbernon) 27 Jun '22

27 Jun '22

v6: Restore temporary todo_wine in PATCH 2, lost in the split. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/310#note_2800

1 0

[PATCH v5 0/5] MR310: mf: Fix several reference leaks.
by Rémi Bernon (＠rbernon) 27 Jun '22

27 Jun '22

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

3 9

[PATCH v4 0/5] MR310: mf: Fix several reference leaks.
by Rémi Bernon (＠rbernon) 27 Jun '22

27 Jun '22

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

3 8

Re: [PATCH v8 0/9] MR6: Avoid performance degradation due to vDSO unmapping (BZ#52313)
by Jinoh Kang (＠iamahuman) 27 Jun '22

27 Jun '22

> 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

1 0

[PATCH v3 0/4] MR310: mf: Fix several reference leaks.
by Rémi Bernon (＠rbernon) 27 Jun '22

27 Jun '22

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

4 8

[PATCH 0/1] MR324: vbscript: Use return_null in more places.
by Robert Wilhelm (＠sloper42) 27 Jun '22

27 Jun '22

Signed-off-by: Robert Wilhelm <robert.wilhelm(a)gmx.net> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/324

3 2

[PATCH v2 0/2] MR305: regedit: Add support for REG_QWORD type.
by Nikolay Sivov (＠nsivov) 27 Jun '22

27 Jun '22

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: regedit: Remove unnecessary string conversion when modifying REG_DWORD value. regedit: Add support for REG_QWORD type. https://gitlab.winehq.org/wine/wine/-/merge_requests/305

4 4

Re: [PATCH v8 0/9] MR6: Avoid performance degradation due to vDSO unmapping (BZ#52313)
by Kevin Puetz (＠puetzk) 27 Jun '22

27 Jun '22

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

1 0

[PATCH v2 0/1] MR312: winex11.drv: Increment configure_serial in X11DRV_WindowPosChanged() even if...
by Paul Gofman (＠gofman) 27 Jun '22

27 Jun '22

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

2 3

[PATCH 0/5] MR322: winex11.drv: Preparation for nulldrv display modes.
by Rémi Bernon (＠rbernon) 27 Jun '22

27 Jun '22

The idea is to have a `add_mode` manager callback and enumerate adapter modes when updating display devices. Then the modes would be read from the registry and cached with the adapters and monitors, allowing us to move more things to win32u. This MR is a preparation towards that, moving the `winex11` settings handler to display.c, and making sure we do not enumerate display modes before they have been initialized or while the list is being built. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/322

3 11

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel