- Wine-devel - list.winehq.org

Re: [PATCH v2 0/3] MR327: ntdll/tests: Tests for bug 53270. - approved
by Alexandre Julliard (＠julliard) 28 Jun '22

28 Jun '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/327

1 0

Re: [PATCH v3 0/1] MR331: winecfg: Support color profiles larger than MAX_PATH chars. - approved
by Alexandre Julliard (＠julliard) 28 Jun '22

28 Jun '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/331

1 0

Re: [PATCH v2 0/6] MR329: light.msstyles: Add Vista+ listview parts. - approved
by Alexandre Julliard (＠julliard) 28 Jun '22

28 Jun '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/329

1 0

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

28 Jun '22

> We cannot reliably detect presence of QEMU When I said "it should at least refuse a MAP_FIXED mmap that would overwrite things the JIT is using", the "it" I had in mind was that qemu-user should do that, not wine-preloader. As you say, wine-preloader doesn't have a good way to know it's running inside qemu. qemu could see that executing this MAP_FIXED would trample on the host proces in ways that compromise the interpreter, and it could choose to make the mmap syscall return MAP_FAILED. > I don't know if there is a significant portion of Wine user base that uses QEMU to run x86 apps on other architectures. I'm actually doing the opposite, which has to be even more niche. We're using qemu-user and binfmt_misc to run unit tests of an aarch64 executable (built with wineg++) on our x86_64 CI server, as part of cross-compiling. This kind of usage has to be vanishingly rare (winelib seems quite rare period). Sorry to have started a somewhat offtopic thread with my comment here. I don't directly think there's much for wine-preloader to do about this. I just stumbled on this merge request in the course of debugging my crash, and was in the same area, and made me think of more alternatives. I had forgotten that using mremap to move `[vdso]` out of the way might even be an option. The main connection is that if this MR makes wine ask to move the vdso out of the way (rather than just having MAP_FIXED clobber it), that seems like something qemu-user might be able to implement and carry on. Just clobbering it seems much harder to tolerate. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6#note_2890

1 0

[PATCH v2 0/2] MR325: pulse/alsa: Set device path for all devices
by Arek Hiler (＠ivyl) 28 Jun '22

28 Jun '22

Required by Cyberpunk 2077 for 4.0 audio setups (`PKEY_AudioEndpoint_PhysicalSpeakers` is `SPEAKER_FRONT_LEFT | SPEAKER_FRONT_RIGHT | SPEAKER_BACK_LEFT | SPEAKER_BACK_RIGHT`) as it then dereferences the device path property (`{b3f8fa53-0004-438e-9003-51a46e139bfc},2`) without checking if is is non-NULL. The patches use `{1}.ROOT\MEDIA\%04u` which is used on Windows for virtual audio devices (e.g. the ones created Voicemeeter Banana). -- v2: winealsa.drv: Set device path for all devices. winepulse.drv: Set device path for all devices. https://gitlab.winehq.org/wine/wine/-/merge_requests/325

4 5

[PATCH v2 0/4] MR313: win32u: Finish moving raw input APIs.
by Zebediah Figura (＠zfigura) 28 Jun '22

28 Jun '22

-- v2: user32: Merge rawinput.c into input.c. win32u: Move raw input device list management from user32. win32u: Move NtUserGetRegisteredRawInputDevices from user32. win32u: Move NtUserRegisterRawInputDevices from user32. https://gitlab.winehq.org/wine/wine/-/merge_requests/313

4 8

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

28 Jun '22

> at least that it should at least refuse a MAP_FIXED mmap that would overwrite things the JIT is using. Unfortunately, there are a few problems in this approach of refusing to overwrite memory mappings used by the QEMU Linux user-mode emulator: 1. **Emulator detection**. We cannot reliably detect presence of QEMU in a way that is guaranteed to work in past and current *as well as* future QEMU versions. Any method of qemu-user detection would rely on the fact that the environment provided by QEMU is different in some way from a native one. As QEMU gets closer and closer to perfectly emulating the real thing, the discrepancies used to detect QEMU will become fewer and fewer, possibly rendering our detection method unusuable. 2. **Bug detection**. In the event that the bug is eventually fixed in a future QEMU version, it's not certain that there will be a way to detect this. For example, the SIGSEGV signal due to vDSO unmapping is not currently forwarded to the guest, so there's no way for the preloader to detect presence of the bug, or absence thereof. I don't know if there is a significant portion of Wine user base that uses QEMU to run x86 apps on other architectures. If this is the case, though, we could implement a (possibly hacky) way to warn the user of such occasion, in a separate patch set. > But changing from a strategy where wine wants to clobber it to one where wine just wants to move it might give qemu-user some better options. I haven't put enough thought into it yet to have a specific idea, just that this PR seemed like it would be helpful. Now, here's the good news: with this patch set, you can elect to avoid unmapping or remapping the vDSO *entirely*. Simply specify the `WINEPRELOADREMAPVDSO=never` environment variable. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6#note_2875

1 0

[PATCH v3 0/1] MR320: riched20/tests: Test for ITextDocument::Undo and ITextDocument::Redo.
by Jinoh Kang (＠iamahuman) 28 Jun '22

28 Jun '22

Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- v3: riched20/tests: Test for ITextDocument::Undo and ITextDocument::Redo. https://gitlab.winehq.org/wine/wine/-/merge_requests/320

2 1

[PATCH 0/2] MR333: kernelbase: Add QueryVirtualMemoryInformation().
by Nikolay Sivov (＠nsivov) 28 Jun '22

28 Jun '22

https://bugs.winehq.org/show_bug.cgi?id=53288 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/333

2 2

[PATCH] comctl32: Add partial support for LVM_SETBKIMAGE.
by Dmitry Timoshkov 28 Jun '22

28 Jun '22

Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/comctl32/listview.c | 65 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 59 insertions(+), 6 deletions(-) diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c index 730bf4aaddd..3ca76c2ef05 100644 --- a/dlls/comctl32/listview.c +++ b/dlls/comctl32/listview.c @@ -91,7 +91,7 @@ * * Messages: * -- LVM_ENABLEGROUPVIEW - * -- LVM_GETBKIMAGE, LVM_SETBKIMAGE + * -- LVM_GETBKIMAGE * -- LVM_GETGROUPINFO, LVM_SETGROUPINFO * -- LVM_GETGROUPMETRICS, LVM_SETGROUPMETRICS * -- LVM_GETINSERTMARK, LVM_SETINSERTMARK @@ -297,6 +297,7 @@ typedef struct tagLISTVIEW_INFO COLORREF clrBk; COLORREF clrText; COLORREF clrTextBk; + HBITMAP hBkBitmap; /* font */ HFONT hDefaultFont; @@ -4567,11 +4568,30 @@ static INT LISTVIEW_GetTopIndex(const LISTVIEW_INFO *infoPtr) */ static inline BOOL LISTVIEW_FillBkgnd(const LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *lprcBox) { - if (!infoPtr->hBkBrush) return FALSE; + if (infoPtr->hBkBitmap) + { + HDC hdc_src = CreateCompatibleDC(hdc); + + TRACE("(hdc=%p, lprcBox=%s, hBkBitmap=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBitmap); + + SelectObject(hdc_src, infoPtr->hBkBitmap); + BitBlt(hdc, lprcBox->left, lprcBox->top, + lprcBox->right - lprcBox->left, + lprcBox->bottom - lprcBox->top, + hdc_src, lprcBox->left, lprcBox->top, SRCCOPY); + + DeleteDC(hdc_src); - TRACE("(hdc=%p, lprcBox=%s, hBkBrush=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBrush); + return TRUE; + } + else if (infoPtr->hBkBrush) + { + TRACE("(hdc=%p, lprcBox=%s, hBkBrush=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBrush); - return FillRect(hdc, lprcBox, infoPtr->hBkBrush); + return FillRect(hdc, lprcBox, infoPtr->hBkBrush); + } + + return FALSE; } /* Draw main item or subitem */ @@ -8028,7 +8048,37 @@ static BOOL LISTVIEW_SetBkColor(LISTVIEW_INFO *infoPtr, COLORREF color) return TRUE; } -/* LISTVIEW_SetBkImage */ +static BOOL LISTVIEW_SetBkImage(LISTVIEW_INFO *infoPtr, const LVBKIMAGEW *image, BOOL isW) +{ + TRACE("%08lx,%p,%p,%u,%d,%d\n", image->ulFlags, image->hbm, image->pszImage, + image->cchImageMax, image->xOffsetPercent, image->yOffsetPercent); + + if (image->ulFlags & ~LVBKIF_SOURCE_MASK) + FIXME("not supported flags %08lx\n", image->ulFlags & ~LVBKIF_SOURCE_MASK); + + if (image->xOffsetPercent || image->yOffsetPercent) + FIXME("not supported offset %d,%d\n", image->xOffsetPercent, image->yOffsetPercent); + + switch (image->ulFlags & LVBKIF_SOURCE_MASK) + { + case LVBKIF_SOURCE_NONE: + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap); + infoPtr->hBkBitmap = 0; + return TRUE; + + case LVBKIF_SOURCE_HBITMAP: + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap); + infoPtr->hBkBitmap = image->hbm; + InvalidateRect(infoPtr->hwndSelf, NULL, TRUE); + return TRUE; + + case LVBKIF_SOURCE_URL: + FIXME("LVBKIF_SOURCE_URL: %s\n", isW ? debugstr_w(image->pszImage) : debugstr_a((LPCSTR)image->pszImage)); + break; + } + + return FALSE; +} /*** Helper for {Insert,Set}ColumnT *only* */ static void column_fill_hditem(const LISTVIEW_INFO *infoPtr, HDITEMW *lphdi, INT nColumn, @@ -10406,6 +10456,7 @@ static LRESULT LISTVIEW_NCDestroy(LISTVIEW_INFO *infoPtr) infoPtr->hFont = 0; if (infoPtr->hDefaultFont) DeleteObject(infoPtr->hDefaultFont); if (infoPtr->clrBk != CLR_NONE) DeleteObject(infoPtr->hBkBrush); + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap); SetWindowLongPtrW(infoPtr->hwndSelf, 0, 0); @@ -11554,7 +11605,9 @@ LISTVIEW_WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) case LVM_SETBKCOLOR: return LISTVIEW_SetBkColor(infoPtr, (COLORREF)lParam); - /* case LVM_SETBKIMAGE: */ + case LVM_SETBKIMAGEA: + case LVM_SETBKIMAGEW: + return LISTVIEW_SetBkImage(infoPtr, (LVBKIMAGEW *)lParam, uMsg == LVM_SETBKIMAGEW); case LVM_SETCALLBACKMASK: infoPtr->uCallbackMask = (UINT)wParam; -- 2.35.3

2 12