July 2026 - Wine-Devel - list.winehq.org

AppDB migration to Content Management System discussion
by Stian Low July 31, 2026

July 31, 2026

AppDB enhancements via CMS open for discussion via: - https://bugs.winehq.org/show_bug.cgi?id=60100

1 0

On implementing the 'beep' escape code in conhost
by Barath Rk July 26, 2026

July 26, 2026

This is in reference to https://bugs.winehq.org/show_bug.cgi?id=50109 Looking at Windows 10, the console 'beep' sound is represented in the registry under the respective key as a path i.e. C:\Windows\media\sound.wav. So the implementation should be as simple as getting the value from this key and calling PlaySound on the retrieved path. Is this the expected way to implement the beep? Also, would it be alright to simply get the .wav files from a Windows 10 install and store them in a windows\media folder when the wine prefix is created or will there be (legal)issues lifting the .wav files from Win10? Regards Barath Kannan

7 29

Wine staging 11.14 release
by Alistair Leslie-Hughes July 25, 2026

July 25, 2026

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.14 (281 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * server: Add support for absolute rawinput mouse messages. * winex11: Clear the MOUSEEVENTF_MOVE flag when accumulating motion. * winex11: Add support for absolute position in RawMotion events. * server: Add send_hardware_message flags for rawinput translation. * winex11: Keep track of mouse device and pointer button mappings. * winex11: Listen to Raw(Motion|Button) events in the desktop thread. * winex11: Send relative RawMotion events position unprocessed. Removed (No longer required). * None Added: * None Updated: * vkd3d-latest Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

[PATCH v2 0/5] ntsync miscellaneous patches
by Elizabeth Figura July 23, 2026

July 23, 2026

This is a resend of a series originally submitted as [1], combined with two patches originally sent as [2]. This supersedes a previous set of patches sent as [3]. The following is the original cover letter sent with the series at [1]. [1] https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/ [2] https://lore.kernel.org/all/20260720175402.44338-1-ivanrwcm25@gmail.com/ [3] https://lore.kernel.org/all/20260720171740.447035-1-zfigura@codeweavers.com/ === This series improves ntsync without changing wait/wake semantics: 1/4 — Align Documentation/userspace-api/ntsync.rst with include/uapi/linux/ntsync.h (ioctl macro names and struct layout). 2/4 — Fix wake_all selftest: CREATE_EVENT returns an fd, not zero. 3/4 — Add selftests for documented EINVAL cases (zero owner, non-zero pad, cross-instance object use). 4/4 — Reject wait ioctls when owner is zero, matching the documented uAPI (3/4 depends on 4/4 for the owner tests). Patch 4/4 closes a spec gap: Documentation/userspace-api/ntsync.rst requires EINVAL when wait owner is zero, but setup_wait() only validated pad and flags. Unlock/kill mutex ioctls already reject owner == 0. Testing: - scripts/checkpatch.pl --strict --no-tree: clean (4/4 patches) - make headers && make -C tools/testing/selftests TARGETS=drivers/ntsync - Kernel 7.1.0-ntsync-test+ (CONFIG_NTSYNC=y), QEMU x86_64 initramfs: tools/testing/selftests/drivers/ntsync/ntsync — 12/12 PASS, including wake_all and wait_args_validation - On 6.17.0-35-generic with the distro ntsync.ko (without patch 4/4): wait_args_validation fails on owner==0 (wait proceeds instead of EINVAL), confirming the gap this series fixes Iván Ezequiel Rodriguez (5): selftests: ntsync: fix wake_all CREATE_EVENT fd expectation selftests: ntsync: add wait argument validation tests ntsync: reject wait ioctls with zero owner docs: ntsync: align ioctl names and struct layouts with uapi selftests: ntsync: test absolute MONOTONIC waits under time namespaces Documentation/userspace-api/ntsync.rst | 33 ++--- drivers/misc/ntsync.c | 3 + .../testing/selftests/drivers/ntsync/ntsync.c | 133 +++++++++++++++++- 3 files changed, 152 insertions(+), 17 deletions(-) base-commit: 2cedf2272f1bb42471e646868ac572cc5752bd91 -- 2.53.0

1 5

[PATCH 0/4] ntsync miscellaneous patches
by Elizabeth Figura July 23, 2026

July 23, 2026

This is a resend of a series originally submitted as [1], now sent to char-misc. The following is the original cover letter sent with that series. [1] https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/ === This series improves ntsync without changing wait/wake semantics: 1/4 — Align Documentation/userspace-api/ntsync.rst with include/uapi/linux/ntsync.h (ioctl macro names and struct layout). 2/4 — Fix wake_all selftest: CREATE_EVENT returns an fd, not zero. 3/4 — Add selftests for documented EINVAL cases (zero owner, non-zero pad, cross-instance object use). 4/4 — Reject wait ioctls when owner is zero, matching the documented uAPI (3/4 depends on 4/4 for the owner tests). Patch 4/4 closes a spec gap: Documentation/userspace-api/ntsync.rst requires EINVAL when wait owner is zero, but setup_wait() only validated pad and flags. Unlock/kill mutex ioctls already reject owner == 0. Testing: - scripts/checkpatch.pl --strict --no-tree: clean (4/4 patches) - make headers && make -C tools/testing/selftests TARGETS=drivers/ntsync - Kernel 7.1.0-ntsync-test+ (CONFIG_NTSYNC=y), QEMU x86_64 initramfs: tools/testing/selftests/drivers/ntsync/ntsync — 12/12 PASS, including wake_all and wait_args_validation - On 6.17.0-35-generic with the distro ntsync.ko (without patch 4/4): wait_args_validation fails on owner==0 (wait proceeds instead of EINVAL), confirming the gap this series fixes Iván Ezequiel Rodriguez (4): docs: ntsync: align uAPI ioctl names and struct layout with ntsync.h selftests: ntsync: fix wake_all CREATE_EVENT fd expectation selftests: ntsync: add wait argument validation tests ntsync: reject wait ioctls with zero owner Documentation/userspace-api/ntsync.rst | 22 ++++----- drivers/misc/ntsync.c | 3 ++ .../testing/selftests/drivers/ntsync/ntsync.c | 46 ++++++++++++++++++- 3 files changed, 59 insertions(+), 12 deletions(-) base-commit: 2cedf2272f1bb42471e646868ac572cc5752bd91 -- 2.53.0

1 5

Re: Please unsubscribe me
by Stian Low July 21, 2026

July 21, 2026

You may unsubscribe yourself from wine-devel via: https://gitlab.winehq.org/wine/wine/-/wikis/Forums#developer-mailing-lists On Tue, Jul 21, 2026 at 11:00 AM Yusuf via Wine-Devel < wine-devel(a)list.winehq.org> wrote: > I dont know how I am subscribed. Please remove me promptly, I don't > support the project. > >

1 0

Upcoming vkd3d 2.1 release
by Henri Verbeet July 20, 2026

July 20, 2026

Hi all, The planned release date for vkd3d 2.1 is Monday August 24. That means the public API will become frozen next week on July 27, and features will be frozen two weeks before the release, on August 10. This does not mean that development should slow down or stop, of course; after making sure that we're in good shape to release, this would be the ideal time to make sure that any larger features are ready to get merged at the start of the next development cycle. As usual, if you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify that all vkd3d tests pass on your hardware/setup, and please send fixes if they don't. - Review and improve the documentation. - Get any larger features ready to get merged at the start of the next development cycle. If you're a downstream user of vkd3d, please test your applications for any regressions, and file bug reports if you find any. The planned release date for vkd3d 2.2 is Monday November 23. A tentative release schedule for future releases can be found on the vkd3d wiki[1]. Regards, Henri [1] https://gitlab.winehq.org/wine/vkd3d/-/wikis/release-schedule

1 0

Re: [PATCH] ntsync: Check for owner in setup_wait()
by Elizabeth Figura July 16, 2026

July 16, 2026

On Tuesday, 14 July 2026 23:56:35 CDT Greg Kroah-Hartman wrote: > On Tue, Jul 14, 2026 at 12:16:47PM -0500, Elizabeth Figura wrote: > > On Tuesday, 14 July 2026 10:36:46 CDT Griffin Kroah-Hartman wrote: > > > Add a check to see if any mutex owner is 0. > > > > > > As stated in the uapi documentation , this is a failure case that was > > > not being checked under the NTSYNC_IOC_WAIT_ANY and NTSYNC_IOC_WAIT_ALL > > > cases, which state that mutexes with no owner should fail the ioctl with > > > -EINVAL. > > > > This has already been sent I'm afraid: > > > > https://lore.kernel.org/all/20260628024239.152852-1-ivanrwcm25@gmail.com/ > > Cool, but that series wasn't sent to the maintainers to get them merged, > and there's going to be a second version as it conflicts with your > previous patches, right? > > Or are you going to batch these up and send them to Arnd and me for > inclusion later on? Ah I'm sorry, I missed that those patches weren't sent to Arnd and you. I'll resend them. The previous patches are in the same situation, but I think these cover a superset of the same ground so I'll just send them alone. > And is the wine-devel list still alive? If not, we should probably drop > that from the MAINTAINERS file. It's alive, but the address moved. I forgot that this reference needed to be updated; I apologize for that. I sent a fix there as <https://lore.kernel.org/all/20260701183214.13973-1-zfigura@codeweavers.com/>. I guess that should also have been sent to you as the relevant subsystem maintainers; I failed to properly think that one through.

1 0

Native arm64 macOS direction: low 4GB, x18, and layout work
by Alexey Rogatkin July 16, 2026

July 16, 2026

Hi, I'm working on a research project around running Windows games on Apple Silicon without Rosetta. It touches both translation layers needed for that: DirectX-to-Metal on the graphics side, and a native macOS CPU-emulation backend for x86-64 code in Wine. FEX already fills a similar role on ARM64 Linux, but upstream FEX currently has no plans to support macOS: https://github.com/FEX-Emu/FEX/discussions/3267 This brought me to the native arm64 macOS Wine runtime work, because that backend needs Wine itself to run as an arm64 process. I currently have a small local series on top of master that gets much further than stock Wine on Apple Silicon: it fixes the host address-space limit probe with a Mach-based path, moves Wine-owned low-address fixtures such as KUSER_SHARED_DATA and the initial TEB block out of the mandatory 4GB __PAGEZERO, adjusts the loader flags needed for native arm64 macOS, and handles the executable-protection issue for PE image code. With that, native arm64 Wine boots a prefix and runs builtin PE applications with winemac.drv. Then I saw Alexandre's note on my GitLab account-verification issue saying that Wine is working with Apple on the low 4GB space and the x18 register, hopefully avoiding Wine-side workarounds. That's exactly the area my local patches touch, so I tried to find the current plan before going further. What I found publicly so far: - Martin Storsjo's 2020 "[PATCH 0/4] macOS/arm64" series. The build fixes were merged, but the runtime issues described there (16KB pages, user_shared_data relocation, W^X) don't seem to have become an upstream runtime solution. - Recent master has useful arm64/ARM64EC groundwork, but I couldn't find anything current for the native macOS low-4GB/x18 work. - x18 seems to be handled differently on Linux; the Darwin side appears to be a separate platform problem. - I couldn't find a current branch, merge request, or wine-devel thread tracking this. I may simply have missed it. My questions are: 1. Is the native arm64 macOS work tracked somewhere public that I should follow, and if not, is there a good way for an outside contributor to get involved? 2. Which parts of this area are worth preparing as Wine merge requests now, and which are expected to be handled by Apple or by another upstream direction? 3. For x18 specifically, is Wine aiming for a durable Apple-provided mechanism, or should a Wine-side loader/toolchain accommodation be considered for now? 4. Does a small shared layout contract for Wine-owned fixed low addresses sound like a reasonable shape, or would maintainers prefer a different model? I'm happy to send the local series as RFC patches, split or reshaped however is most useful. I'd much rather align with Wine's architecture than carry private platform plumbing. For the record, I've worked only from public documentation, independent tests, and public sources such as Wine, FEX-Emu, Apple's open-source XNU drops, and Microsoft's public ARM64EC ABI documentation. I have not looked at Microsoft Windows source code. Best regards, Alexey Rogatkin

3 2

Wine staging 11.13 release
by Alistair Leslie-Hughes July 11, 2026

July 11, 2026

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.13 (282 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * None Updated: * vkd3d-latest * odbc32 patchset Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

[PATCH] MAINTAINERS: Update wine-devel list address
by Elizabeth Figura July 1, 2026

July 1, 2026

Wine mailing lists were moved from winehq.org to list.winehq.org in December 2025. The old address no longer works. Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 15011f5752a9..e4d7af3d0cb0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19296,7 +19296,7 @@ F: fs/ntfs3/ NTSYNC SYNCHRONIZATION PRIMITIVE DRIVER M: Elizabeth Figura <zfigura(a)codeweavers.com> -L: wine-devel(a)winehq.org +L: wine-devel(a)list.winehq.org S: Supported F: Documentation/userspace-api/ntsync.rst F: drivers/misc/ntsync.c base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482 -- 2.53.0

1 0