January 2026 - Wine-gitlab - list.winehq.org

Re: [PATCH v2 0/4] MR9775: gdiplus: Move X position calculation to callbacks.
by Esme Povirk (＠madewokherd) 26 Jan '26

26 Jan '26

The character range results look very wrong with my own test program: [measuretext.c](/uploads/66d1d1ff10f3728fc6f0e83c4bf587a4/measuretext.c) Character ranges are always ending up on the first line in the case of wrapped text, and apparently always start at X=0. It's also strange to me that any of the callbacks have to care about Y alignment, and unclear to me why we should redesign them to handle X alignment. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9775#note_128018

1 0

[PATCH 0/11] MR9974: dwrite/tests: Add more tests for GetClusterMetrics().
by Nikolay Sivov (＠nsivov) 26 Jan '26

26 Jan '26

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9974

2 11

[PATCH v34 0/1] MR9868: winewayland: Fix non-square icons with xdg-toplevel-icon protocol.
by Alex Schwartz (＠alexschwartz01) 26 Jan '26

26 Jan '26

Currently, it will stop the app that is running that has a non-square icon This PR fixes that -- v34: winewayland: Fix non-square icons with xdg-toplevel-icon protocol. https://gitlab.winehq.org/wine/wine/-/merge_requests/9868

3 5

[PATCH 0/4] MR9973: Draft: conhost: add basic VT control sequence
by Thomas Csovcsity (＠thc13) 26 Jan '26

26 Jan '26

This is a minimal approach to running MC in wineconsole. Wineconsole thus supports basic CSI control sequences for: - SGR (Select Graphic Rendition) and - CUP (Cursor Position) ![mc-in-wineconsole-260126](/uploads/36ed70375b31955fa44dc477e832242c/mc-in-wineconsole-260126.gif){width=900 height=507} -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9973

2 4

Re: [PATCH v8 0/2] MR9369: wininet: Return correct errors and put handle into invalid state when seeking beyond end of file.
by Jacek Caban (＠jacek) 26 Jan '26

26 Jan '26

Jacek Caban (@jacek) commented about dlls/wininet/http.c: > else if(req->state == INTERNET_HANDLE_IN_USE) > req->state = ERROR_INTERNET_INTERNAL_ERROR; > > + if (req->state != ERROR_SUCCESS) { That looks suspicious, we ensure that it's not `ERROR_SUCCESS` just before that check. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9369#note_128009

1 0

[PATCH v2 0/3] MR9963: windows.ui: Add corewindow_static_GetForCurrentThread() stub.
by Zhiyi Zhang (＠zhiyi) 26 Jan '26

26 Jan '26

For React Native. -- v2: windows.ui: Add corewindow_static_GetForCurrentThread() stub. windows.ui/tests: Add tests for corewindow_static_GetForCurrentThread(). windows.ui: Add ICoreWindowStatic stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/9963

2 4

[PATCH 0/3] MR9963: windows.ui: Add corewindow_static_GetForCurrentThread() stub.
by Zhiyi Zhang (＠zhiyi) 26 Jan '26

26 Jan '26

For React Native. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9963

3 6

[PATCH v2 0/4] MR9913: Draft: winedmo: Allow building against multiple and specific FFmpeg versions.
by Rémi Bernon (＠rbernon) 26 Jan '26

26 Jan '26

This would achieve ABI compatibility with arbitrary FFmpeg versions, without having to redefine / fixup FFmpeg structures manually. Downstream Wine distributions may be interested in having an embedded but crippled FFmpeg shipped with them, avoiding issues related to FFmpeg distribution, while still being able to dynamically load the system, or externally provided, more capable FFmpeg version. The distributions would only need to build every supported winedmo versions, targeting the corresponding FFmpeg ABI, to later dynamically load them. The non-versioned winedmo would load the distribution embedded FFmpeg for instance, while the versioned modules would target a matching system library. This also introduces an unified interface with winegstreamer, allowing us to get rid of the duplicated media source code. -- v2: winedmo: Load winedmo for specific FFmpeg versions dynamically. winedmo: Allow building winedmo against multiple FFmpeg versions. winedmo: Expose function tables instead of individual functions. mfsrcsnk: Use function pointers for winedmo demuxer functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/9913

3 12

[PATCH v4 0/3] MR7659: windows.devices.bluetooth: Add implementation for IBluetoothStatics::GetDefaultAsync(), BluetoothAdapter.
by Vibhav Pant (＠vibhavp) 26 Jan '26

26 Jan '26

This MR adds a basic implementation for the BluetoothAdapter interface in Windows.Devices.Bluetooth, including winebth.sys support for getting properties associated with the radio's Low Energy capabilities. -- v4: windows.devices.bluetooth: Implement BluetoothAdapter::get_BluetoothAddress. windows.devices.bluetooth: Implement IBluetoothAdapterStatics::GetDefaultAsync(). windows.devices.bluetooth/tests: Add tests for IBluetoothAdapter. https://gitlab.winehq.org/wine/wine/-/merge_requests/7659

3 5

[PATCH v12 0/1] MR9840: winepulse.drv: A potential solution to audio crackling
by Dzmitry Keremsha (＠Vyrolian) 26 Jan '26

26 Jan '26

I have noticed that winepulse leaves too little headroom when draining the buffer, which very often leads to crackling that can't be fully resolved by manipulating latency. Let's check some math: Let's assume that the buffer (tlength) is at 33ms, and minreq is at 13.3ms. If 13.2 ms were drained, the refill would be denied. If the next timer trigger takes 14ms due to jitter, that leaves us with a 6.1ms margin. As such, if we get any jitter longer than that during refill, we get an underflow. I think this is what leads to crackles. My solution increases timer polling to 5x the frequency, so if 13.2ms were drained, the next timer trigger would happen at around 16ms. That would leave us with a 17ms headroom. The math might not be 100% representation of what happens, but I think it's quite close to reality. On practice, this does indeed help to fully get rid of crackling for an indefinite amount of time, when before they were unevitable. I think this problem is quite urgent, because while this does not happen on every system, it's frequent enough that we see "Audio: Crackling" reports on most games on protondb and there are many forum threads about audio crackling. From my experience, the only solution was switching to winealsa, which is very consistent and does not crackle at all. My experience has been very consistent with forum threads when it came to the nature of crackling. I first noticed it in Balatro, which is a very light game and should not be crackling at all on any setup. Some games have very frequent crackling every 20-30 seconds, or buzzsaw crackling every 10-15 minutes. I hope my idea brings us closer to the ultimate fix, I really look forward to your feedback! -- v12: winepulse.drv: Increase timer frequency https://gitlab.winehq.org/wine/wine/-/merge_requests/9840

2 2