Trivial, small set of cleanups patches to start with, non-controversial and NOP functionally speaking.
These are to help get the review process going in making ways towards the bar being lowered for contributing to the oleaut32 implementation.
Signed-off-by: Edward O'Callaghan <edward(a)antitrust.cc>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7375
Tidy Cauldron (2708320), a Unity game, uses EnumWindows() to find the first window in the current
thread and maximizes the window when changing to windowed mode. However, before this patch, the IME
UI window and the DXGI fallback device window are on top of the game window at creation and thus
they could get maximized instead. This causes the game window to lose focus and freeze.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7381
The current YUV to RGB conversion provides values in studio-range [16-235], but full-range is required [0-255]. As a result, we currently write the value of 16 to represent black, and so we get gray instead.
This MR changes the coefficients used in the conversion so that the resultant output is in full-range. It actually uses two sets of coefficients as these differ between SD and HD.
Also included is a number of Direct Draw 7 tests.
The coefficients used are documented here:
https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-…
--
v4: wined3d: Use Microsoft provided coefficients for YUV to RGB conversion.
ddraw/tests: Test yuv to rgb blt in ddraw7.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7324
The current YUV to RGB conversion provides values in studio-range [16-235], but full-range is required [0-255]. As a result, we currently write the value of 16 to represent black, and so we get gray instead.
This MR changes the coefficients used in the conversion so that the resultant output is in full-range. It actually uses two sets of coefficients as these differ between SD and HD.
Also included is a number of Direct Draw 7 tests.
The coefficients used are documented here:
https://learn.microsoft.com/en-us/windows/win32/medfound/recommended-8-bit-…
--
v3: wined3d: Use Microsoft provided coefficients for YUV to RGB conversion.
ddraw/tests: Test yuv to rgb blt in ddraw7.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7324
Fix the wayland side of https://bugs.winehq.org/show_bug.cgi?id=55336
### Exit menu key by default:
That's the actual behavior, any non-special key will exit the menu key, and be sent to the client.
I was also wondering if we should add `menu_sys_key = f10_key = 0;` when receiving a `WM_ACTIVATE` in `win32u/defwnd.c`'s `default_window_proc` but I guess not ?
### Fix repeated key for no reason:
For some reason when ALT is pressed, it is spammed and thus spams SYS_COMMAND. This fix that, but I don't know what I am doing here. I don't see any repeating key spamming with winex11 but I could be wrong. However alt/SYS_COMMAND should not be repeated.
That wasn't happening with winex11.drv.
### Fix release_all_keys modifier filtering:
That was the main reason why alt-tab leads to the menu key, NtUserGetAsyncKeyboardState also uses left and right system keys.
--
v9: win32u: Default to exit when tracking top menu
https://gitlab.winehq.org/wine/wine/-/merge_requests/6199
Fix the wayland side of https://bugs.winehq.org/show_bug.cgi?id=55336
### Exit menu key by default:
That's the actual behavior, any non-special key will exit the menu key, and be sent to the client.
I was also wondering if we should add `menu_sys_key = f10_key = 0;` when receiving a `WM_ACTIVATE` in `win32u/defwnd.c`'s `default_window_proc` but I guess not ?
### Fix repeated key for no reason:
For some reason when ALT is pressed, it is spammed and thus spams SYS_COMMAND. This fix that, but I don't know what I am doing here. I don't see any repeating key spamming with winex11 but I could be wrong. However alt/SYS_COMMAND should not be repeated.
That wasn't happening with winex11.drv.
### Fix release_all_keys modifier filtering:
That was the main reason why alt-tab leads to the menu key, NtUserGetAsyncKeyboardState also uses left and right system keys.
--
v8: win32u: Default to exit when tracking top menu
winewayland.drv: Fix release_all_keys modifier filtering
https://gitlab.winehq.org/wine/wine/-/merge_requests/6199
Make both method calls;
1. Consistently written with parameter names as per spec.
2. Fix parameter validation to be consistent with spec.
3. Fix szNameBuf parameter semantics as per spec.
4. Fix szNameBuf casing str search as per spec.
5. Factor out common code into TLB_ helpers vastly improves readability.
--
v29: oleaut32: Fix buffers in MSFT_Do{Funcs,Vars}()
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7286
This adds Mach thread priority support (both in the application and realtime band) and recalculates thread priorities when the process priority changes.
Part 3, which is still a bit WIP deals with implementing priority boosts (for main threads and threads which are processing window messages), effectively fully replacing https://gitlab.winehq.org/wine/wine/-/merge_requests/1232.
Currently the implementation in this MR already technically overrides what https://gitlab.winehq.org/wine/wine/-/merge_requests/1232 does, if it makes sense I can also revert it here.
I added a few comments regarding the Mach thread priority API usage, as there is limited documentation available, and much was inferred from the source or by testing. If this is too verbose I can also remove that...
--
v3: server: Apply Mach thread priorities after process tracing is initialized.
server: Implement apply_thread_priority on macOS for realtime priorities.
server: Implement apply_thread_priority on macOS for application priorities.
kernel32/tests: Setting process priority on a terminated process should succeed.
server: Also set thread priorities upon process priority change.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7317
Instead of checking for monitor rect.
Similar purpose as https://gitlab.winehq.org/wine/wine/-/merge_requests/7362
--
v2: winewayland: Pass fullscreen flag to is_window_managed.
winex11: Pass fullscreen flag to is_window_managed.
winex11: Check managed window changes in WindowPosChanged.
winex11: Request managed window changes asynchronously.
winex11: Initialize window managed flag in create_whole_window.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7370
Add Expat as a dependency, and use it to parse the XML returned from FreeBSD's kern.sched.topology_spec sysctl.
--
v4: ntdll: implement create_logical_proc_info on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7339
This is an attempt at improving X11 focus handling, and will most importantly be useful to later better handle dynamic window decoration changes on any mutter-based window manager. These window managers do a little dance in that case, unmapping/mapping the window every time decoration are added/removed, and we often get confused by the focus events it triggers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7182
This broke after d58e917e2cb36c6ffcb259356c06171d8f6d4dcc in some situations, since it resulted in us calling wined3d_texture_download_from_texture() with CLEARED location. The latter was not aware of CLEARED and incorrectly assumed the source texture was in TEXTURE_SRGB.
--
v2: wined3d: Explicitly check for BUFFER/SYSMEM before calling wined3d_texture_download_from_texture().
wined3d: Propagate a CLEARED location when blitting.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7313
commit cb87d40cd4a8837826ea76efc91371ab09eb9d63 removed the ability (from the inside the tools/wine-wrapper) to have some local settings (per build tree) where one can adapt environment for launching wine
this MR allows at configure time to specify an (external) wine wrapper to use for a given build tree
Signed-off-by: Eric Pouech epouech(a)codeweavers.com
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7361
The Microsoft WMV decoder has a bug/feature where orientation of
the first output type determines the orientation for all subsequent
RGB output types.
If the transform is created new, then the orientation is determined by
the value of the MF_MT_DEFAULT_STRIDE.
This MR adds tests for that behavior and implements it in Wine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7366
This adds Mach thread priority support (both in the application and realtime band) and recalculates thread priorities when the process priority changes.
Part 3, which is still a bit WIP deals with implementing priority boosts (for main threads and threads which are processing window messages), effectively fully replacing https://gitlab.winehq.org/wine/wine/-/merge_requests/1232.
Currently the implementation in this MR already technically overrides what https://gitlab.winehq.org/wine/wine/-/merge_requests/1232 does, if it makes sense I can also revert it here.
I added a few comments regarding the Mach thread priority API usage, as there is limited documentation available, and much was inferred from the source or by testing. If this is too verbose I can also remove that...
--
v2: server: Re-apply thread priorities after process tracing is initialized.
server: Implement apply_thread_priority on macOS for realtime priorities.
server: Implement apply_thread_priority on macOS for application priorities.
kernel32/tests: Setting process priority on a terminated process should succeed.
server: Also set thread priorities upon process priority change.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7317
Make both method calls;
1. Consistently written with parameter names as per spec.
2. Fix parameter validation to be consistent with spec.
3. Fix szNameBuf parameter semantics as per spec.
4. Fix szNameBuf casing str search as per spec.
5. Factor out common code into TLB_ helpers vastly improves readability.
--
v28: dlls/oleaut32: Read in the hashmap data while loading typelib
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7286
The Windows Bluetooth stack uses private IOCTLs in order to set the [discoverability](https://learn.microsoft.com/en-us/windows/win32/api/blueto… and [connectability](https://learn.microsoft.com/en-us/windows/win32/api/bluetoo… status of a local radio. This MR introduces the wine-specific IOCTL `IOCTL_WINBTH_RADIO_SET_FLAG` for the same purpose, as most applications seem to the Win32 API itself for these operations.
--
v16: bluetoothapis: Implement BluetoothEnableDiscovery.
bluetoothapis/tests: Add tests for BluetoothEnableDiscovery.
bluetoothapis: Add stub for BluetoothEnableDiscovery.
bluetoothapis: Implement BluetoothEnableIncomingConnections.
bluetoothapis/tests: Add tests for BluetoothEnableIncomingConnections.
bluetoothapis: Add stub for BluetoothEnableIncomingConnections.
winebth.sys: Call bluez_watcher_close as part of bluetooth_shutdown.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_SET_FLAG.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7216
The Windows Bluetooth stack uses private IOCTLs in order to set the [discoverability](https://learn.microsoft.com/en-us/windows/win32/api/blueto… and [connectability](https://learn.microsoft.com/en-us/windows/win32/api/bluetoo… status of a local radio. This MR introduces the wine-specific IOCTL `IOCTL_WINBTH_RADIO_SET_FLAG` for the same purpose, as most applications seem to the Win32 API itself for these operations.
--
v15: bluetoothapis: Implement BluetoothEnableDiscovery.
bluetoothapis/tests: Add tests for BluetoothEnableDiscovery.
bluetoothapis: Add stub for BluetoothEnableDiscovery.
bluetoothapis: Implement BluetoothEnableIncomingConnections.
bluetoothapis/tests: Add tests for BluetoothEnableIncomingConnections.
bluetoothapis: Add stub for BluetoothEnableIncomingConnections.
winebth.sys: Call bluez_watcher_close as part of bluetooth_shutdown.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_SET_FLAG.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7216
The Windows Bluetooth stack uses private IOCTLs in order to set the [discoverability](https://learn.microsoft.com/en-us/windows/win32/api/blueto… and [connectability](https://learn.microsoft.com/en-us/windows/win32/api/bluetoo… status of a local radio. This MR introduces the wine-specific IOCTL `IOCTL_WINBTH_RADIO_SET_FLAG` for the same purpose, as most applications seem to the Win32 API itself for these operations.
--
v14: bluetoothapis: Implement BluetoothEnableDiscovery.
bluetoothapis/tests: Add tests for BluetoothEnableDiscovery.
bluetoothapis: Add stub for BluetoothEnableDiscovery.
bluetoothapis: Implement BluetoothEnableIncomingConnections.
bluetoothapis/tests: Add tests for BluetoothEnableIncomingConnections.
bluetoothapis: Add stub for BluetoothEnableIncomingConnections.
winebth.sys: Call bluez_watcher_close as part of bluetooth_shutdown.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_SET_FLAG.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7216
The Windows Bluetooth stack uses private IOCTLs in order to set the [discoverability](https://learn.microsoft.com/en-us/windows/win32/api/blueto… and [connectability](https://learn.microsoft.com/en-us/windows/win32/api/bluetoo… status of a local radio. This MR introduces the wine-specific IOCTL `IOCTL_WINBTH_RADIO_SET_FLAG` for the same purpose, as most applications seem to the Win32 API itself for these operations.
--
v13: bluetoothapis: Implement BluetoothEnableDiscovery.
bluetoothapis/tests: Add tests for BluetoothEnableDiscovery.
bluetoothapis: Add stub for BluetoothEnableDiscovery.
bluetoothapis: Implement BluetoothEnableIncomingConnections.
bluetoothapis/tests: Add tests for BluetoothEnableIncomingConnections.
bluetoothapis: Add stub for BluetoothEnableIncomingConnections.
winebth.sys: Call bluez_watcher_close as part of bluetooth_shutdown.
winebth.sys: Implement IOCTL_WINEBTH_RADIO_SET_FLAG.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7216
Fixes a bug where music on the radio in Fallout 3 is silent.
Upon receiving EOS, the game resets the position of the stream and then calls `IMediaControl_Run()` without calling `IMediaControl_Stop()`. In wine, this results in the `got_ec_complete` variable being uncleared, and the stream position is stuck at end of stream.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7358
Some compositors (e.g., kwin) will send a done event for every commit,
regardless of the focus state of the text input. This behavior is
arguably(?) out of spec, but otherwise harmless, so just ignore the new
state in such cases.
--
To reproduce (without the fix) simple open notepad under kwin and change the focus do a different window. The root cause of this is that kwin is responding to the disable&commit we perform on text_input leave.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7359
This is the refactoring of the tests in !7160. I submit a new seperate MR because I want to get the tests upstreamed first, otherwise making changes to tests patches needs rebasing the implementation patches. So plz review the tests MR first.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7332
If a surface is being clipped and hides the cursor, drawing its own one,
winewayland constrains using a pointer lock and enables Wayland relative
motion. If the application decides to stop drawing its own cursor and
make the cursor visible, winewayland will disable relative motion and
pointer lock, and enable pointer confinement. The user will perceive a
pointer jump from the win32/application drawn cursor to where the
Wayland pointer is after being unlocked and an absolute motion event is
received, because they were desynchronized due to the Wayland one being
locked in place.
The pointer constraints protocol says this:
> If the client is drawing its own cursor, it should update the position
> hint to the position of its own cursor. A compositor may use this
> information to warp the pointer upon unlock in order to avoid pointer
> jumps.
So, right before unlocking, make a request for the compositor to warp
the pointer to the win32 position on pointer unlock.
--
v2: winewayland: Request warp to win32 position on pointer unlock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7352
--
v2: oleaut32: Add support for decoding SLTG variable help strings.
oleaut32: Add support for decoding SLTG function help strings.
oleaut32: Implement decoding of SLTG help strings.
oleaut32: 'typekind' is the last field of SLTG_OtherTypeInfo structure.
oleaut32: Fix logic for deciding whether type description follows the name.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7334
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57665
---
The issue is that The Medium launcher uses a dialog window procedure, and implements its background by doing a StretchBlt call on WM_PAINT in the dialog procedure call, which happens before the window message loop.
It then itself calls InvalidateRect(hwnd, NULL, 0), which queues a WM_PAINT as well but with only the RDW_INVALIDATE flag.
Next, when the window message loop is executed, the WM_PAINT message is being processed as it should, but as we've invalidate the window with RDW_ERASE ourselves from the expose event, the WM_NCPAINT handler erases the entire window, clearing the pixels that the launcher has just painted.
This regressed since the window surface clipping region logic changed, as the expose event handling was previously not calling `NtUserRedrawWindow` on windows with a surface and without a clipping region. The clipping region was also previously not always set, or set later, and we're setting it more consistently since 51b16963f6e0e8df43118deac63f640aee4698b7, even when it matches the window rect, for compatibility with some old wineandroid logic (where I believe it was used to clip window surfaces to their proper sizes).
--
v3: winex11: Avoid setting RDW_ERASE on expose events.
explorer: Paint the desktop even without RDW_ERASE.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7157
This cleans up `LDR_DONT_RESOLVE_REFS` checks in preparation for !7.
--
v4: ntdlll: Remove redundant LDR_DONT_RESOLVE_REFS checks before calling process_attach().
ntdll: Skip DLL initialization and ldr notification entirely if DONT_RESOLVE_DLL_REFERENCES is set.
kernel32/tests: Test for unexpected loader notification for import dependency loaded with DONT_RESOLVE_DLL_REFERENCES.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7347
There is no ([not yet?](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requ…) dedicated protocol for requesting pointer warps, but it's possible to request one with `zwp_locked_pointer_v1.set_cursor_position_hint` which may be performed when the pointer is unlocked. The idea is to quickly lock/set position/unlock. This is used by SDL (in some cases: [SDL_MOUSE_EMULATE_WARP_WITH_RELATIVE](https://wiki.libsdl.org/SDL3/SDL_HINT…) and Xwayland. The limitation is/will be that the compositor will ignore requests to warp the pointer outside of surface bounds.
What I'd like to have working is the auto cursor placement feature of some applications, where they just want to call SetCursorPos towards specific UI elements inside their single window, and usually they'll be unclipped and have a visible cursor while doing this.
This patch also happens to allow mouselook to work in applications which use SetCursorPos for mouselook and aren't getting covered by the heuristics that turn on Wayland relative motion (for some reason the driver thinks the cursor is visible). Seems to affect Half-Life (GoldSrc) on my system. Though force enabling relative motion with an environment variable in a custom build or somehow improving the heuristics will also fix that.
A suface/pointer can only have one lock or confinement, and this implementation depends on the pointer lock. So if needed, I temporarily unlock/unconfine in order to do the warp then relock/reconfine. I modified `wayland_pointer_update_constraint` so I don't have to temporarily disable relative motion during this in case it's enabled. I think it's safe/a no-op to attempt pointer warps while using relative motion, as according to the protocol the warp will not generate a relative motion event, and while there will be a wl_pointer motion event, they're ignored while relative motion is being used.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7353
If a surface is being clipped and hides the cursor, drawing its own one,
winewayland constrains using a pointer lock and enables Wayland relative
motion. If the application decides to stop drawing its own cursor and
make the cursor visible, winewayland will disable relative motion and
pointer lock, and enable pointer confinement. The user will perceive a
pointer jump from the win32/application drawn cursor to where the
Wayland pointer is after being unlocked and an absolute motion event is
received, because they were desynchronized due to the Wayland one being
locked in place.
The pointer constraints protocol says this:
> If the client is drawing its own cursor, it should update the position
> hint to the position of its own cursor. A compositor may use this
> information to warp the pointer upon unlock in order to avoid pointer
> jumps.
So, right before unlocking, make a request for the compositor to warp
the pointer to the win32 position on pointer unlock.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7352
On Tue Feb 18 06:30:29 2025 +0000, Nikolay Sivov wrote:
> I knew I commented on these changes before, but then I found it was
> !7244. Could we merge those, or what's the plan?
No problem to do that if 11 commits are ok.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7174#note_94962
Startup and lock counts in native Windows are separate, and the lock count does not decrease when an async result is freed if the platform has been started.
--
v5: rtworkq: Introduce an async result object cache.
rtworkq: Introduce a platform startup count.
rtworkq/tests: Test work queue.
mfplat/tests: Test platform startup and lock counts.
mfplat/tests: Test mixing of MF platform functions with their Rtwq equivalents.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7174
Port the XML parser from dlls/ntdll/actctx.c to ASCII and use it to parse
the XML returned from FreeBSD's kern.sched.topology_spec sysctl.
--
v3: ntdll: implement create_logical_proc_info on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7339
This cleans up `LDR_DONT_RESOLVE_REFS` checks in preparation for !7.
--
v3: ntdlll: Remove redundant LDR_DONT_RESOLVE_REFS checks before calling process_attach().
ntdll: Skip DLL initialization and ldr notification entirely if DONT_RESOLVE_DLL_REFERENCES is set.
kernel32/tests: Test for unexpected loader notification for import dependency loaded with DONT_RESOLVE_DLL_REFERENCES.
kernel32/tests: Test for unexpected LDR_PROCESS_ATTACHED flag in import dependency loaded with DONT_RESOLVE_DLL_REFERENCES.
kernel32/tests: Add basic tests for internal flags of modules loaded with DONT_RESOLVE_DLL_REFERENCES.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7347
On Wed Jan 1 16:32:32 2025 +0000, Nikolay Sivov wrote:
> @alexhenrie is it possible to create a drive without a letter? Regarding
> wine supporting only drives with assigned letters, I don't think it
> matters that much if it turns out to be easy to return a correct path.
> IDrive has separate properties for paths and letters, so maybe there is
> a reason for that.
My understanding is that the way to query all available drives is via DriveCollection. Due to this I changed the tests to what Alex Henrie suggested as it will properly verify the functionality of the function.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7060#note_94929
This is a bit convoluted because of the amount of pieces involved. I'll
try to untangle things a bit.
The container id is meant to be globally unique and stable. We therefore
need a suitable amount of stable entropy that we can feed into a hash
function to get a stable and unique output.
This happens in winebus. The corner stone of hash inputs is the linux
device topology (sysfs path) obtained via udev. Along with all other
possible data we feed this into a hash function to obtain our container
id.
A bunch of extra wine-specific keys needed to be added to carry the
necessary metadata from the driver into the ntoskrnl (where it gets
written to the property registry of the relevant device).
Separate from this we also ingest the linux device topology (sysfs path)
in the winepulse driver.
In mmdevapi we then use winepulse's sysfs path to find the matching
device in the setupapi and query its container id. We now have the same
container id in both the device and the MMDevice, allowing applications
(in particular Games) to find the MMDevice for a given device.
For practical reasons we always resolve the sysfs path to the root
device as early as possible. Container ids are meant to be equal for sub
devices inside a "container" anyway.
--
v4: containerid: helper to generate a containerid from a sysfs path
mmdevapi: correctly read and write containerid as clsid blob
https://gitlab.winehq.org/wine/wine/-/merge_requests/7238