- wine-gitlab - winehq.org

Re: [PATCH v7 0/15] MR7516: Server-side thread priorities implementation (Part 3)
by Rémi Bernon (＠rbernon) 18 Mar '25

18 Mar '25

Rémi Bernon (@rbernon) commented about include/winternl.h: > UINT64 InheritedFromUniqueProcessId; > } PROCESS_BASIC_INFORMATION64; > > -#define PROCESS_PRIOCLASS_IDLE 1 > -#define PROCESS_PRIOCLASS_NORMAL 2 > -#define PROCESS_PRIOCLASS_HIGH 3 > -#define PROCESS_PRIOCLASS_REALTIME 4 > -#define PROCESS_PRIOCLASS_BELOW_NORMAL 5 > -#define PROCESS_PRIOCLASS_ABOVE_NORMAL 6 > +#define PROCESS_PRIORITY_CLASS_UNKNOWN 0 > +#define PROCESS_PRIORITY_CLASS_IDLE 1 > +#define PROCESS_PRIORITY_CLASS_NORMAL 2 > +#define PROCESS_PRIORITY_CLASS_HIGH 3 > +#define PROCESS_PRIORITY_CLASS_REALTIME 4 > +#define PROCESS_PRIORITY_CLASS_BELOW_NORMAL 5 > +#define PROCESS_PRIORITY_CLASS_ABOVE_NORMAL 6 I haven't found neither the PROCESS_PRIOCLASS nor the PROCESS_PRIORITY_CLASS constants in the SDK headers, where are you seeing them? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7516#note_98242

1 0

Re: [PATCH v7 0/15] MR7516: Server-side thread priorities implementation (Part 3)
by Rémi Bernon (＠rbernon) 18 Mar '25

18 Mar '25

Rémi Bernon (@rbernon) commented about include/winnt.h: > #define THREAD_BASE_PRIORITY_MIN -2 > #define THREAD_BASE_PRIORITY_IDLE -15 > > +#define LOW_PRIORITY 0 /* Lowest thread priority level */ > +#define LOW_REALTIME_PRIORITY 16 /* Lowest realtime priority level */ > +#define HIGH_PRIORITY 31 /* Highest thread priority level */ > +#define MAXIMUM_PRIORITY 32 /* Number of thread priority levels */ > + This should be in `ddk/wdm.h`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7516#note_98241

1 0

[PATCH 0/2] MR7606: user32/edit: Block key input when mouse input is captured.
by Nikolay Sivov (＠nsivov) 18 Mar '25

18 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56108 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7606

3 3

[PATCH v2 0/2] MR7595: comctl32/tests: Add a test for LVM_FINDITEM with LVS_OWNERDATA.
by Nikolay Sivov (＠nsivov) 18 Mar '25

18 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57746 Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: comctl32/listview: Use correct LVN_ODFINDITEM notification. comctl32/tests: Add a test for LVM_FINDITEM with LVS_OWNERDATA. https://gitlab.winehq.org/wine/wine/-/merge_requests/7595

3 3

[PATCH v2 0/5] MR7466: mf: Fix some issues with seeking.
by Conor McCarthy (＠cmccarthy) 18 Mar '25

18 Mar '25

This fixes failure to play the prologue video in Planet of the Apes: Last Frontier, which unpauses by calling Start() with a location. The exact state leading to this issue does not occur in the Start() tests, and it's not clear how to reproduce it reliably. -- v2: mf: Reset transform nodes when seeking. mf: Initialise the grabber sample count when setting state after a seek. mf: Reset transform node outputs when seeking. mf: Drop transform node input events when unpausing at a specific position. https://gitlab.winehq.org/wine/wine/-/merge_requests/7466

3 7

[PATCH v3 0/5] MR7559: cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification.
by Vibhav Pant (＠vibhavp) 18 Mar '25

18 Mar '25

The methods are needed to implement Bluetooth device pairing in `bluetoothapis.dll` without having to create a dummy window for `RegisterDeviceNotification`, as that may break CLI applications. `CM_Register_Notification` is implemented as a thin wrapper over `I_ScRegisterDeviceNotification`, mapping `DBT_*` flags to their associated `CM_NOTIFY_*` constants. -- v3: user32: Remove incorrect FIXME warning while registering for DBT_DEVTYP_HANDLE notifications. cfgmgr32: Implement CM_Register_Notification and CM_Unregister_Notification. dinput/tests: Add tests for CM_Register_Notification. cfgmgr32/tests: Add basic tests for CM_(Un)Register_Notification. https://gitlab.winehq.org/wine/wine/-/merge_requests/7559

3 7

[PATCH 0/1] MR3862: user32/tests: Ignore other messages in test_broadcast.
by Esme Povirk (＠madewokherd) 18 Mar '25

18 Mar '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54194 If the SendMessageTimeout call takes a long time, we can get other messages which also set the observed wparam value. Apparently, this is especially likely on Windows 7. This also removes the (wParam == 0xbaadbeef) check which may have been intended to serve the same goal but doesn't work because the observed wParam value is still assigned. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3862

3 2

[PATCH v3 0/1] MR7344: winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow.
by Dmitry Timoshkov (＠dmitry) 18 Mar '25

18 Mar '25

Original patch description https://www.winehq.org/pipermail/wine-patches/2017-February/157574.html winehq.org no longer provides the wine-patches archives, so it's necessary to dig into [web.archive.org](https://web.archive.org/web/20211011014926/https://www.win…: https://web.archive.org/web/20211011014926/https://www.winehq.org/pipermail… https://web.archive.org/web/20211011014930/https://www.winehq.org/pipermail… =================================================================== Based on a patch by Dmitry Timoshkov. ## Signed-off-by: Sebastian Lackner sebastian(a)fds-team.de Fixes https://bugs.winehq.org/show_bug.cgi?id=33943. Battle.Net initially creates completely transparent popup windows and afterwards uses UpdateLayeredWindow without hdcSrc to let them fade in. Testing confirms that this works fine on Windows - on Wine however the original content is lost and no longer available. To avoid that, this patch stores the original content in the surface and uses \_NET_WM_WINDOW_OPACITY to create a transparency effect. The same method is already used by SetLayeredWindowAttributes. If compositing is disabled, the window content will be visible immediately. Dmitrys original patch used a different approach, and manually implemented the alpha blending in x11drv_surface_flush using additional buffers, however this shouldn't really be necessary (yet). We can still use it later if there is any benefit compared to using \_NET_WM_WINDOW_OPACITY. -- v3: winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow. https://gitlab.winehq.org/wine/wine/-/merge_requests/7344

3 9

[PATCH v3 0/1] MR7594: msvcrt: Add _IONBF flag check in _filbuf to avoid dead loop in application which sets the flag.
by Kun Yang (＠yangkun) 18 Mar '25

18 Mar '25

Signed-off-by: Kun Yang <yangkun(a)uniontech.com> Change-Id: Ia68e11ccb0aa563eeb73a2f5cb93afcd328e1937 [fgetws_test.7z](/uploads/7b706f2c4f639e4260c548d834658b32/fgetws_test.7z) If the application calls setvbuf(.., _IONBF, ..) before fgetws, wine sets the flag. In fgetws, this flag is not checked. read_i is called with paramenter count 1 which is not allowed in read_i implemantion. Function read_i returns -1 and the file stream is not actually read by program. The file pointer is not moved. If the application writes fgetws in a loop, it never reach EOF and falls in dead loop. By adding check for _IONBF in _filbuf, the application will run into another branch(file->_bufsiz=2). Thats's correct. Please checkout the example in my attachment. This application exits normally in Windows but falls in dead loop in wine. -- v3: msvcrt: Add MSVCRT__NOBUF flag check in _filbuf to avoid dead loop in application which sets the flag. https://gitlab.winehq.org/wine/wine/-/merge_requests/7594

3 2

Re: [PATCH v3 0/6] MR7530: win32u, server: Improve tracking mouse messages from pointer messages.
by Rémi Bernon (＠rbernon) 18 Mar '25

18 Mar '25

On Tue Mar 11 14:30:34 2025 +0000, Paul Gofman wrote: > I don't see how to avoid that in principle? > - the logic is triggered by calling DefWindowProc, so we can't avoid > some action from DefWindowProc; > - after WM_POINTERUPDATE with changing coordinates the messages should > be generated (and, separately, updating cursor position) regardless of > DefWindowProc calls; also generating that in DefWindowProc or > accept_hardware_message would be clumsy because > NtUserSendHardwareInput() can't generate the exact message we need, that > would need some custom interface (and won't avoid a server call to send > message anyway); > - we could in principle stop sending those `track_mouse_from_pointer` > calls once the tracking switched to server side (by returning the > corresponding flag from this call and tracking this part of state in > thread data), but we also want to update driver cursor position which > seems to cope nicely with this call, in that case it would need to be > done in some other more complicated ways. So reducing the amount of > those calls (by not sending them once server tracking started) is > possible but it will require these parts. I thought it doesn't add too > much of calls, do you think it worth it? > EDIT: updated. I don't know, this call feels inherently racy and I would like to give it more thought and time to check how windows behave. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7530#note_98225

1 0

2025

2024

2023

2022

wine-gitlab