list.winehq.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Wine-gitlab

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
wine-gitlab@list.winehq.org

November 2025

  • 1 participants
  • 1084 discussions
[PATCH 0/1] MR9486: windowscodecs: correct GIF LZW compression initialization
by Jiajin Cui (@jin-king1) 22 Jan '26

22 Jan '26
The GIF LZW compression algorithm was incorrectly initializing the code size to 8 bits regardless of the actual color depth. This caused issues with images that have fewer colors requiring smaller initial code sizes. The fix calculates the proper initial code size based on the actual number of colors in the image, using the formula: minimum code size = max(2, ceil(log2(color_count))). This ensures proper compression for images with small color palettes and maintains compatibility with GIF decoders that expect correct LZW initialization parameters. Log: Fixed GIF compression for images with small color palettes Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9486
6 9
0 0
[PATCH v13 0/3] MR7539: combase : clsid_from_string_reg() add read of CurVer key value.
by Maotong Zhang (@xiaotong) 21 Jan '26

21 Jan '26
If the read ProgID only has a CurVer key and no CLSID key, it will directly return CO_E_CCLASSSTRING, causing the program to fail to continue running. Add the key value for finding CurVer. -- v13: combase:clsid_from_string_reg() add read of CurVer key value. ole32:Do not zero out when not a CLSID ole32/tests:Remove now succeeding todo_wine https://gitlab.winehq.org/wine/wine/-/merge_requests/7539
4 6
0 0
[PATCH 0/1] MR9629: configure: Add option for building with split debug info.
by Yuxuan Shui (@yshui) 15 Jan '26

15 Jan '26
* * * all the machinery for split debug info is there, and the only thing needed is just exposing a flag from `configure`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9629
4 5
0 0
[PATCH v3 0/3] MR7429: winex11: Support absolute rawinput events and use window-relative coordinates.
by Rémi Bernon 14 Jan '26

14 Jan '26
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51357 Now that we're tracking window position changes as they arrive, they should always be consistent with the received mouse input events. Absolute rawinput is useful for tablets, touchpad or touchscreen when they are exposed as absolute mouse devices. -- v3: winex11: Use window-relative coordinates for mouse input. winex11: Add support for absolute position in RawMotion events. winex11: Clear the MOUSEEVENTF_MOVE flag when accumulating motion. https://gitlab.winehq.org/wine/wine/-/merge_requests/7429
3 6
0 0
[PATCH 0/1] MR8452: Draft: gitlab: Set WINEPREFIX to a job workspace sub-directory.
by Rémi Bernon 14 Jan '26

14 Jan '26
Although I have trouble reproducing it I still experience weird test failures whenever I create or updated separate MRs in a short amount of time. These failures are usually coming from unexpected display settings, although each job is running within docker in an isolated environment. I don't have any explanation for this, and I have confirmed that separate X server are spawned. However, the prefix used for the tests is initialized to /home/gitlab/.wine and I suspect this could perhaps be mounted and shared across containers? It could also explain the failures, if, for instance wineserver starts while another instance (invisible as isolated in a separate container) is running and has updated the registry on disk with different display settings while the tests are being executed. This is hypothetical but nonetheless I think it's better to keep the prefix in a job workspace sub-directory. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8452
3 6
0 0
[PATCH v2 0/4] MR9510: Draft: win32u: Implement timeline semaphore rewinding.
by Rémi Bernon 14 Jan '26

14 Jan '26
Pretty much the same kind of thing Proton does, this is only for non-shared semaphores for now. This creates timeline events backed by host timeline semaphores, for every wait and signal operation on a client timeline semaphore. Events are host timeline semaphores with monotonically increasing values. One event is a `(host semaphore, value)` unique tuple, and their value is incremented every time they get signaled. They can be reused right away as a different event, with the new value. Signaled events are queued to a per-device event list for reuse, as we cannot safely destroy them [^1] and as creating them might be costly. A thread is spawned for every device that uses timeline semaphores, monitoring the events and semaphore value changes. The semaphore wrapper keeps the current client semaphore value, which is read directly by `vkGetSemaphoreCounterValue`. CPU and GPU waits on the client semaphore are swapped with a wait on a timeline event, and GPU signals with a signal on a timeline event. CPU signals simply update the client semaphore value on the wrapper, signaling the timeline thread to check and notify any waiter. The timeline thread waits on signal events, coming from the GPU, and on a per-device semaphore for CPU notifications (wait/signal list updates, CPU-side signal). It will then signal any pending wait for a client semaphore value that has been reached, and removes timed out waits. --- For shared semaphores my idea is to use the client timeline semaphore host handle itself as a signal to notify other device threads of semaphore value changes, as the host semaphore is what is exported and imported in other devices. The timeline threads would wait on that semaphore too in addition to the signal events and thread notification semaphore. The main issue with shared semaphores actually comes from sharing the client semaphore values, so that they can be read from each device timeline threads as well as from other processes. There's two scenarios to support, one that is for in-process sharing which could perhaps keep the information locally, but we also need to support cross-process sharing so I think there's no other way than to involve wineserver. My idea then is to move shared semaphore client value to wineserver, which will cost a request on every signal and wait (and reading the value for waits could later be moved to a shared memory object). This will also allow us to implement `D3DKMTWaitForSynchronizationObjectFromCpu` which might be useful for D3D12 fence implementation as it'll allow us to translate a timeline semaphore wait to an asynchronous NT event signal. [^1]: Vulkan spec indicates that semaphores may only be destroyed *after* every operation that uses them has fully executed, and it's unclear whether signaling or waiting a semaphore is enough as an indicator for full execution or whether we would need to wait on a submit fence. -- v2: win32u: Implement timeline semaphore rewinding support. win32u: Make a copy of the timeline semaphore value arrays. win32u: Spawn a device thread for timeline semaphores. win32u: Hook more vulkan timeline semaphore functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/9510
3 9
0 0
[PATCH 0/1] MR4709: winedbg: Show all loaded modules in automatic backtrace.
by Bernhard Übelacker 10 Jan '26

10 Jan '26
This patch should change the module list in the automatic backtraces from "info share" to "info wow share". That way all loaded modules should get listed instead of just the process native ones. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4709
3 5
0 0
[PATCH v7 0/1] MR3410: advpack: Add nullcheck for parameter that can be null (Coverity)
by Fabian Maurer (@DarkShadow44) 08 Jan '26

08 Jan '26
-- v7: advpack: Add nullchecks for parameters that can be null (Coverity) https://gitlab.winehq.org/wine/wine/-/merge_requests/3410
4 8
0 0
[PATCH v3 0/2] MR9398: Don't try to activate a window in set_window_pos if it's set as active in GUITHREADINFO.
by Santino Mazza (@tati) 10 Dec '25

10 Dec '25
This prevents a window from getting reactivated when calling `SetWindowPos` inside the WM_ACTIVATE handler. For now I only was able to reproduce this by triggering a change in the active window from X11 with an alt-tab or by clicking another window, I was not able to write a wine test for this. This test program works for reproducing it. ```c #include <windows.h> LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { if (uMsg == WM_ACTIVATE) { SetWindowPos(hwnd, 0, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE); } done: return DefWindowProc(hwnd, uMsg, wParam, lParam); } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pCmdLine, int nCmdShow) { HWND hwnd; const char CLASS_NAME[] = "class"; WNDCLASSA wc = {}; wc.lpfnWndProc = WindowProc; wc.hInstance = hInstance; wc.lpszClassName = CLASS_NAME; RegisterClass(&wc); hwnd = CreateWindowEx(0, CLASS_NAME, "test", 0, 4, 4, 1024, 768, NULL, NULL, hInstance, NULL); ShowWindow(hwnd, SW_SHOW); MSG msg; while (TRUE) { GetMessage(&msg, NULL, 0, 0); TranslateMessage(&msg); DispatchMessage(&msg); } } ``` -- v3: win32u: Don't activate a window that is being deactivated. https://gitlab.winehq.org/wine/wine/-/merge_requests/9398
4 6
0 0
[PATCH 0/1] MR6459: ntdll: Support Ctrl-C stop debuggee and attach 32-bit process in wow64 mode.
by JiangYi Chen (@meshine) 09 Dec '25

09 Dec '25
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6459
3 3
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • ...
  • 109
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.