- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/1] MR8992: mountmgr.sys: Do not create empty registry nodes for serial or parallel devices.
by Alexandre Julliard (＠julliard) Sept. 20, 2025

Sept. 20, 2025

No, you should keep the same merge request and force-push the new version to the same branch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8992#note_116525

1 0

[PATCH 0/4] MR8932: combobox: Don't update item height on WM_SETFONT for owner drawn CB.
by Paul Gofman (＠gofman) Sept. 20, 2025

Sept. 20, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8932

3 6

Re: [PATCH v2 0/1] MR8992: mountmgr.sys: Do not create empty registry nodes for serial or parallel devices.
by Janne Kekkonen (＠Janne) Sept. 20, 2025

Sept. 20, 2025

I modified my code so that is takes into account user defined ports. Should i close this request and create new one? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8992#note_116522

1 0

[PATCH v2 0/1] MR9015: mf: Implement MFTranscodeGetAudioOutputAvailableTypes().
by Nikolay Sivov (＠nsivov) Sept. 20, 2025

Sept. 20, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58717 Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: mf: Implement MFTranscodeGetAudioOutputAvailableTypes(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9015

2 1

[PATCH 0/5] MR9008: mmdevapi/tests: Rewrite capturing tests, part 3/4.
by Giovanni Mascellani (＠giomasce) Sept. 20, 2025

Sept. 20, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9008

3 6

[PATCH v2 0/1] MR9018: po: Update Finnish translation.
by Lauri Kenttä Sept. 20, 2025

Sept. 20, 2025

-- v2: po: Update Finnish translation. https://gitlab.winehq.org/wine/wine/-/merge_requests/9018

1 1

[PATCH 0/1] MR9018: po: Update Finnish translation.
by Lauri Kenttä Sept. 20, 2025

Sept. 20, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9018

1 1

[PATCH 0/1] MR9017: po: update Polish translation
by Adam Markowski (＠AMark) Sept. 20, 2025

Sept. 20, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9017

2 1

[PATCH v2 0/1] MR8999: win32u: Fix garbled 24-bit bitmap rendering
by Zowie van Dillen (＠zowie) Sept. 20, 2025

Sept. 20, 2025

Fixes https://bugs.winehq.org/show_bug.cgi?id=58620 I've made this a separate MR from !8969 because that MR contains a lot of highly debatable architectural decisions (such as FAKE_16BIT_MEMDC_PIXEL_FORMAT and all of its special case branches). This MR is very minimal and straight to the point. -- v2: win32u: Fix garbled 24-bit bitmap rendering https://gitlab.winehq.org/wine/wine/-/merge_requests/8999

3 5

[PATCH v3 0/5] MR8969: opengl32, win32u: Fix 16-bit PFD_DRAW_TO_BITMAP rendering.
by Zowie van Dillen (＠zowie) Sept. 20, 2025

Sept. 20, 2025

This MR fixes 16-bit PFD_DRAW_TO_BITMAP rendering, as tested with SimGolf and Civilization 3. The fix isn't super performant since it involves a lot of back-and-forth between CPU and GPU, which is mostly noticeable when moving staff around in SimGolf — it slows to around two or three fps —, but on the plus side it does work, which is a straight upgrade over the current version of Wine. Couple of notes: * The third commit touches several different subsystems because I had to add a constant that's visible from both opengl32 and win32u. I wasn't sure how to write this down in the commit message. * There's a bug in LLVMpipe where a 32-bit pbuffer will cause it to crash. I opened an issue for it here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13890. I needed a 32-bit pbuffer to make this work, so I added a special check that effectively disables 16-bit bitmap rendering for LLVMpipe. * I also had to use a workaround to make blitting & OpenGL rendering work together. I wrote about it pretty extensively below. ## Combining blitting & OpenGL rendering Something that's difficult about bitmap rendering is that it allows programs to combine OpenGL drawing with direct blitting onto bitmap memory. That's difficult to imitate with the pbuffer-based implementation because there's no way to replicate memory edits on the bitmap to the GPU-based pbuffer (since there's no API calls involved in the memory edit). This had to work to make the games actually work, so I used this workaround: Each time after overwriting the bitmap from the pbuffer, we clear the pbuffer with transparent. Also instead of "overwriting" the bitmap, we instead blend the pbuffer's pixels onto the bitmap. That way we're effectively overlaying the most recent OpenGL drawings on top of the bitmap. I'm pretty confident that that approach would also help with 32-bit and 24-bit bitmap rendering, but I don't know of any programs that use 32-bit or 24-bit bitmap rendering, so I wasn't able to check. I've just left 32-bit and 24-bit bitmaps as they were. While the workaround works really well for the games, I did have to edit another test because it used glReadPixels on 16-bit bitmaps. glReadPixels will grab pixels from the transparent-background pbuffer instead of the bitmap, which gives the wrong result. I'm not under the impression that any consumer programs use bitmap rendering together with glReadPixels (it doesn't make as much sense when you could just directly read the pixels from the bitmap), but it's possible to add a wrap_glReadPixels that grabs pixels from the bitmap in case of a 16-bit memory DC. It's not important to read but I wanted to write it down for the record: I also tried another workaround to make combining blitting & OpenGL work. The thought was to overwrite the pbuffer with the bitmap just before OpenGL draws to the pbuffer, to keep them in sync. It probably would have worked out if it was possible to add something to the front of the OpenGL command buffer in a glFinish/glFlush call — then I could have inserted glDrawPixels in the front, before all of the program's rendering operations —, but it's only possible to add things to the end of the command buffer unfortunately. I tried adding a wrapper to glBegin and glClear, which checks if they were the first render operation after a glFlush or glFinish. Unfortunately that didn't work at all. I'm guessing that Civ 3 and SimGolf still do direct bitmap edits after the first call to glBegin, so by the time the program gets to glFinish/glFlush the pixels that were uploaded in the glDrawPixels command are already stale (although I didn't really check). Anyhow, that approach was pretty fruitless. -- v3: win32u: Fix garbled 24-bit bitmap rendering win32u: Add support for 16-bit bitmaps to set_dc_pixel_format and flush_memory_dc. opengl32: Return a fake pixel format when requesting 16-bit bitmap rendering. opengl32/tests: Extend 16-bit bitmap rendering test. winex11: Refine PFD_DRAW_TO_BITMAP requirements. https://gitlab.winehq.org/wine/wine/-/merge_requests/8969

2 5

[PATCH v4 0/5] MR9000: win32u: Check the queue access time from the shared memory.
by Rémi Bernon Sept. 19, 2025

Sept. 19, 2025

This is a step in the direction of continuously polling the queue fd on the server side, removing the need for ntsync to notify wineserver before / after waiting on the queue. For this my plan is to make win32u also notify wineserver to update the queue access time before waiting (through set_queue_mask), if it's been long enough. Then decide that a queue is hung based on whether it is signaled but access time is more than 5s ago (ie: neither get_message nor set_queue_mask are called regularly even though queue is signaled). On the server side, the queue fd would stop being polling once it gets ready, and win32u would notify wineserver after all the driver events have been processed, to start polling it again, as a separate request from the wait. -- v4: win32u: Check the queue access time from the shared memory. server: Use monotonic_time as queue access time base. win32u: Move the message queue access time to shared memory. server: Move hooks_count to the end of the queue_shm_t struct. server: Return early if there's no queue in queue requests. https://gitlab.winehq.org/wine/wine/-/merge_requests/9000

2 9

[PATCH 0/1] MR9016: po: Update Lithuanian translation.
by Aurimas Fišeras Sept. 19, 2025

Sept. 19, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9016

1 1

Re: [PATCH v2 0/6] MR9011: Cmd engine rewrite (part XXXV) - approved
by Alexandre Julliard (＠julliard) Sept. 19, 2025

Sept. 19, 2025

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

1 0

Re: [PATCH v3 0/3] MR9005: ShowWindow paramater usage - approved
by Alexandre Julliard (＠julliard) Sept. 19, 2025

Sept. 19, 2025

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

1 0

Re: [PATCH v2 0/2] MR9004: win32u: Avoid swapping / flushing drawables with destroyed windows. - approved
by Alexandre Julliard (＠julliard) Sept. 19, 2025

Sept. 19, 2025

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

1 0

Re: [PATCH v3 0/1] MR9007: wmic: Add a basic help option "/?". - approved
by Alexandre Julliard (＠julliard) Sept. 19, 2025

Sept. 19, 2025

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

1 0

Re: [PATCH v7 0/1] MR8928: msxml3/tests: add test for IXMLDOMElement_removeAttributeNode. - approved
by Alexandre Julliard (＠julliard) Sept. 19, 2025

Sept. 19, 2025

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

1 0

Re: [PATCH v4 0/8] MR8966: d3dx: Miscellaneous fixes. - approved
by Alexandre Julliard (＠julliard) Sept. 19, 2025

Sept. 19, 2025

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

1 0

Re: [PATCH v4 0/4] MR8991: iphlpapi: Implement GetBestRoute2() and GetBestInterfaceEx(). - approved
by Alexandre Julliard (＠julliard) Sept. 19, 2025

Sept. 19, 2025

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

1 0

Re: [PATCH v2 0/1] MR9002: po: update Polish translation - approved
by Alexandre Julliard (＠julliard) Sept. 19, 2025

Sept. 19, 2025

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

1 0

[PATCH 0/1] MR9015: mf: Implement MFTranscodeGetAudioOutputAvailableTypes().
by Nikolay Sivov (＠nsivov) Sept. 19, 2025

Sept. 19, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58717 Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9015

2 1

[PATCH v8 0/14] MR8995: Draft: ntdll/kernelbase: Add accurate node count feature to prevent memory access violations initializing multiple physical nodes as a single logical one on multi-node systems
by Danny Waser (＠wasertech) Sept. 19, 2025

Sept. 19, 2025

A much cleaner result (written by hand) that we can reuse where needed later (_i.e._ `GetNumaProcessorNode` which also crashes with [a similar MAV](https://gist.github.com/wasertech/f894ce8d6250e72a01a861c0e4eb6064) on multi-node systems). Took me a while to understand where I should put everything, not even sure I got it right. Let me know. I thought I was going to need `FileNumaNodeInformation` but turns out it's not really needed. I can remove it if you want. This is what I see when I try to get a node count read: ```log 0024:fixme:ntdll:init_numa_info node affinity; using node 0. GetNumaHighestNodeNumber: 1 ``` I only see this fixme if I try to access `FILE_NUMA_NODE_INFORMATION`. I would really prefer such a behavior for our compatibility layer on any multi-node system. A big thanks to @besentv and @zfigura for their invaluable feedback on this. -- v8: ntdll: improve error handling in NtQuerySystemInformationEx https://gitlab.winehq.org/wine/wine/-/merge_requests/8995

3 16

[PATCH v2 0/3] MR9005: ShowWindow paramater usage
by Alistair Leslie-Hughes (＠alesliehughes) Sept. 19, 2025

Sept. 19, 2025

This patchset is just to correct the parameter passed to ShowWindow. -- v2: wordpad: Correct show parameter passed to ShowWindow cryptui: Correct show parameter passed to ShowWindow comdlg32: Correct show parameter passed to ShowWindow https://gitlab.winehq.org/wine/wine/-/merge_requests/9005

4 5

[PATCH v2 0/1] MR8742: mf: Handle start request when session is already running.
by Bernhard Kölbl Sept. 19, 2025

Sept. 19, 2025

Starting the session while it's already running should not resume anything. -- v2: mf: Handle start request when session is already running. https://gitlab.winehq.org/wine/wine/-/merge_requests/8742

2 5

Re: [PATCH v8 0/2] MR8955: ntdll: NtSetEventBoostPriority stub regression fixes for bug #58688
by Elizabeth Figura (＠zfigura) Sept. 19, 2025

Sept. 19, 2025

> But it's likely something already known, if it wow64 specific. Well, it might also be CPU-specific. I can reproduce it here, though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8955#note_116455

1 0