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

AppDB migration to Content Management System discussion

by Stian Low

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

July 31, 2026

Re: On implementing the 'beep' escape code in conhost

by Barath Rk

Any updates on this? I realized that if we will be working towards implementing Beep, this MR won't even be necessary lol(after implementing Beep, it would be one line change in conhost to implement the \a code for write_console) On Fri, Jul 24, 2026 at 4:38 PM Barath Rk <barathrk11(a)gmail.com> wrote: > > https://gitlab.winehq.org/wine/wine/-/merge_requests/11469 > > I have created an MR for this issue. This produces a simple double > beep as the bell. > > I haven't added any tests as I was unsure about them. > > On Fri, Jul 24, 2026 at 1:08 PM Barath Rk <barathrk11(a)gmail.com> wrote: > > > > >from an architecture point of view, kernel(base|32) is at a "layer" > > >below winmm (and any other sound related DLLs) > > > > Hm right > > > > > yes to decide if we reuse and existing service or add a new one > > yeah fair enough. I think I'll just generate my own beep effect using > > winmm for this fix though. simplest option currently > > > > On Fri, Jul 24, 2026 at 12:58 PM Eric Pouech <eric.pouech(a)orange.fr> wrote: > > > > > > Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit : > > > > Could you explain what you mean by it being a layering issue? the > > > > waveOut* functions of winmm essentially call the respective audio > > > > drivers. By "service" do you mean pulse/ALSA? > > > > > > from an architecture point of view, kernel(base|32) is at a "layer" > > > below winmm (and any other sound related DLLs) > > > > > > so winmm is allowed to call into kernel(base[32), but not the other way > > > around > > > > > > Zeb suggests we have a service responding to a beep ctl command (and > > > that service could call into winmm) > > > > > > yes to decide if we reuse and existing service or add a new one > > > > > >

July 26, 2026

Wine staging 11.14 release

by Alistair Leslie-Hughes

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.

July 25, 2026

Re: On implementing the 'beep' escape code in conhost

by Barath Rk

https://gitlab.winehq.org/wine/wine/-/merge_requests/11469 I have created an MR for this issue. This produces a simple double beep as the bell. I haven't added any tests as I was unsure about them. On Fri, Jul 24, 2026 at 1:08 PM Barath Rk <barathrk11(a)gmail.com> wrote: > > >from an architecture point of view, kernel(base|32) is at a "layer" > >below winmm (and any other sound related DLLs) > > Hm right > > > yes to decide if we reuse and existing service or add a new one > yeah fair enough. I think I'll just generate my own beep effect using > winmm for this fix though. simplest option currently > > On Fri, Jul 24, 2026 at 12:58 PM Eric Pouech <eric.pouech(a)orange.fr> wrote: > > > > Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit : > > > Could you explain what you mean by it being a layering issue? the > > > waveOut* functions of winmm essentially call the respective audio > > > drivers. By "service" do you mean pulse/ALSA? > > > > from an architecture point of view, kernel(base|32) is at a "layer" > > below winmm (and any other sound related DLLs) > > > > so winmm is allowed to call into kernel(base[32), but not the other way > > around > > > > Zeb suggests we have a service responding to a beep ctl command (and > > that service could call into winmm) > > > > yes to decide if we reuse and existing service or add a new one > > > >

July 24, 2026

Re: On implementing the 'beep' escape code in conhost

by Barath Rk

>from an architecture point of view, kernel(base|32) is at a "layer" >below winmm (and any other sound related DLLs) Hm right > yes to decide if we reuse and existing service or add a new one yeah fair enough. I think I'll just generate my own beep effect using winmm for this fix though. simplest option currently On Fri, Jul 24, 2026 at 12:58 PM Eric Pouech <eric.pouech(a)orange.fr> wrote: > > Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit : > > Could you explain what you mean by it being a layering issue? the > > waveOut* functions of winmm essentially call the respective audio > > drivers. By "service" do you mean pulse/ALSA? > > from an architecture point of view, kernel(base|32) is at a "layer" > below winmm (and any other sound related DLLs) > > so winmm is allowed to call into kernel(base[32), but not the other way > around > > Zeb suggests we have a service responding to a beep ctl command (and > that service could call into winmm) > > yes to decide if we reuse and existing service or add a new one > >

July 24, 2026

Re: On implementing the 'beep' escape code in conhost

by Eric Pouech

Le 24/07/2026 à 07:01, Barath Rk via Wine-Devel a écrit : > Could you explain what you mean by it being a layering issue? the > waveOut* functions of winmm essentially call the respective audio > drivers. By "service" do you mean pulse/ALSA? from an architecture point of view, kernel(base|32) is at a "layer" below winmm (and any other sound related DLLs) so winmm is allowed to call into kernel(base[32), but not the other way around Zeb suggests we have a service responding to a beep ctl command (and that service could call into winmm) yes to decide if we reuse and existing service or add a new one

July 24, 2026

Re: On implementing the 'beep' escape code in conhost

by Barath Rk

Could you explain what you mean by it being a layering issue? the waveOut* functions of winmm essentially call the respective audio drivers. By "service" do you mean pulse/ALSA? If we were to implement Beep without calls to winmm from kernelbase, I suppose we would have to forward the request like it is already being done, but to something more agnostic than conhost. How would one go about this though? I thought of a server request, but I realize server changes are quite rare. On Fri, Jul 24, 2026 at 1:31 AM Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > > On Thursday, 23 July 2026 12:49:32 CDT Barath Rk via Wine-Devel wrote: > > > but I don't have strong objection for playing a predefined sound instead > > directly from conhost > > > > If that is the case, would it be better to first create a proper > > implementation of Beep(that doesn't rely on forwarding to conhost. I > > suppose this should be possible with whatever winmm provides right now) and > > then use that here? > > The trouble with that is layering; it's surely wrong to call winmm or anything audio from kernelbase. It may be that it calls out to a service. > >

July 24, 2026

[PATCH v2 5/5] selftests: ntsync: test absolute MONOTONIC waits under time namespaces

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Cover the timens conversion in ntsync_schedule(): with a negative CLOCK_MONOTONIC offset, a 100 ms absolute wait must not return immediately against the host clock. Suggested-by: Maoyi Xie <maoyixie.tju(a)gmail.com> Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- .../testing/selftests/drivers/ntsync/ntsync.c | 87 +++++++++++++++++++ 1 file changed, 87 insertions(+) diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c index c9fe4d5987ec..1f0dc43bb4c0 100644 --- a/tools/testing/selftests/drivers/ntsync/ntsync.c +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c @@ -8,12 +8,18 @@ #define _GNU_SOURCE #include <sys/ioctl.h> #include <sys/stat.h> +#include <sys/wait.h> #include <fcntl.h> +#include <sched.h> #include <time.h> #include <pthread.h> #include <linux/ntsync.h> #include "kselftest_harness.h" +#ifndef CLONE_NEWTIME +#define CLONE_NEWTIME 0x00000080 +#endif + static int read_sem_state(int sem, __u32 *count, __u32 *max) { struct ntsync_sem_args args; @@ -1384,4 +1390,85 @@ TEST(wait_args_validation) close(fd); } +/* + * Absolute MONOTONIC timeouts must honour the caller's time namespace. + * With a negative monotonic offset, a 100 ms wait must still take ~100 ms + * of namespace time (not return immediately against the host clock). + */ +TEST(wait_any_monotonic_timens) +{ + struct ntsync_sem_args sem_args = {0}; + struct ntsync_wait_args wait_args = {0}; + struct timespec start, end; + char buf[64]; + __u64 elapsed_ns; + int fd, offset_fd, sem, ret, status, len; + pid_t pid; + + if (access("/proc/self/ns/time", F_OK)) + SKIP(return, "Time namespaces are not supported"); + + fd = open("/dev/ntsync", O_CLOEXEC | O_RDONLY); + if (fd < 0) + SKIP(return, "/dev/ntsync is not available"); + + ret = unshare(CLONE_NEWTIME); + if (ret) { + close(fd); + if (errno == EPERM) + SKIP(return, "need CAP_SYS_ADMIN for CLONE_NEWTIME"); + ASSERT_EQ(0, ret); + } + + len = snprintf(buf, sizeof(buf), "%d %d 0", CLOCK_MONOTONIC, -10); + offset_fd = open("/proc/self/timens_offsets", O_WRONLY); + ASSERT_LE(0, offset_fd); + ASSERT_EQ(len, write(offset_fd, buf, len)); + close(offset_fd); + + pid = fork(); + ASSERT_LE(0, pid); + if (!pid) { + int obj; + + sem_args.count = 0; + sem_args.max = 1; + sem = ioctl(fd, NTSYNC_IOC_CREATE_SEM, &sem_args); + if (sem < 0) + _exit(1); + + obj = sem; + wait_args.timeout = get_abs_timeout(100); + wait_args.objs = (uintptr_t)&obj; + wait_args.count = 1; + wait_args.owner = 123; + wait_args.index = 0xdeadbeef; + + if (clock_gettime(CLOCK_MONOTONIC, &start)) + _exit(2); + ret = ioctl(fd, NTSYNC_IOC_WAIT_ANY, &wait_args); + if (clock_gettime(CLOCK_MONOTONIC, &end)) + _exit(2); + + if (ret != -1 || errno != ETIMEDOUT) + _exit(3); + + elapsed_ns = (end.tv_sec - start.tv_sec) * 1000000000ULL + + (end.tv_nsec - start.tv_nsec); + /* Without timens conversion this returns in ~0 ms. */ + if (elapsed_ns < 50 * 1000000ULL) + _exit(4); + if (elapsed_ns > 1000 * 1000000ULL) + _exit(5); + + _exit(0); + } + + ASSERT_EQ(pid, waitpid(pid, &status, 0)); + EXPECT_TRUE(WIFEXITED(status)); + EXPECT_EQ(0, WEXITSTATUS(status)); + + close(fd); +} + TEST_HARNESS_MAIN -- 2.53.0

July 23, 2026

[PATCH v2 4/5] docs: ntsync: align ioctl names and struct layouts with uapi

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> The uAPI documentation used outdated or conceptual ioctl macro names and listed ntsync_event_args / ntsync_wait_args fields in the wrong order. Match include/uapi/linux/ntsync.h and note that absolute MONOTONIC timeouts are interpreted in the caller's time namespace. Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- Documentation/userspace-api/ntsync.rst | 33 +++++++++++++------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/Documentation/userspace-api/ntsync.rst b/Documentation/userspace-api/ntsync.rst index 25e7c4aef968..a778016feb87 100644 --- a/Documentation/userspace-api/ntsync.rst +++ b/Documentation/userspace-api/ntsync.rst @@ -83,18 +83,18 @@ structures used in ioctl calls:: }; struct ntsync_event_args { - __u32 signaled; __u32 manual; + __u32 signaled; }; struct ntsync_wait_args { __u64 timeout; __u64 objs; __u32 count; - __u32 owner; __u32 index; - __u32 alert; __u32 flags; + __u32 owner; + __u32 alert; __u32 pad; }; @@ -152,7 +152,7 @@ The ioctls on the device file are as follows: The ioctls on the individual objects are as follows: -.. c:macro:: NTSYNC_IOC_SEM_POST +.. c:macro:: NTSYNC_IOC_SEM_RELEASE Post to a semaphore object. Takes a pointer to a 32-bit integer, which on input holds the count to be added to the semaphore, and on @@ -186,7 +186,7 @@ The ioctls on the individual objects are as follows: unowned and signaled, and eligible threads waiting on it will be woken as appropriate. -.. c:macro:: NTSYNC_IOC_SET_EVENT +.. c:macro:: NTSYNC_IOC_EVENT_SET Signal an event object. Takes a pointer to a 32-bit integer, which on output contains the previous state of the event. @@ -194,12 +194,12 @@ The ioctls on the individual objects are as follows: Eligible threads will be woken, and auto-reset events will be designaled appropriately. -.. c:macro:: NTSYNC_IOC_RESET_EVENT +.. c:macro:: NTSYNC_IOC_EVENT_RESET Designal an event object. Takes a pointer to a 32-bit integer, which on output contains the previous state of the event. -.. c:macro:: NTSYNC_IOC_PULSE_EVENT +.. c:macro:: NTSYNC_IOC_EVENT_PULSE Wake threads waiting on an event object while leaving it in an unsignaled state. Takes a pointer to a 32-bit integer, which on @@ -213,7 +213,7 @@ The ioctls on the individual objects are as follows: afterwards, and a simultaneous read operation will always report the event as unsignaled. -.. c:macro:: NTSYNC_IOC_READ_SEM +.. c:macro:: NTSYNC_IOC_SEM_READ Read the current state of a semaphore object. Takes a pointer to struct :c:type:`ntsync_sem_args`, which is used as follows: @@ -225,7 +225,7 @@ The ioctls on the individual objects are as follows: * - ``max`` - On output, contains the maximum count of the semaphore. -.. c:macro:: NTSYNC_IOC_READ_MUTEX +.. c:macro:: NTSYNC_IOC_MUTEX_READ Read the current state of a mutex object. Takes a pointer to struct :c:type:`ntsync_mutex_args`, which is used as follows: @@ -242,7 +242,7 @@ The ioctls on the individual objects are as follows: ``EOWNERDEAD``. In this case, ``count`` and ``owner`` are set to zero. -.. c:macro:: NTSYNC_IOC_READ_EVENT +.. c:macro:: NTSYNC_IOC_EVENT_READ Read the current state of an event object. Takes a pointer to struct :c:type:`ntsync_event_args`, which is used as follows: @@ -255,7 +255,7 @@ The ioctls on the individual objects are as follows: - On output, contains 1 if the event is a manual-reset event, and 0 otherwise. -.. c:macro:: NTSYNC_IOC_KILL_OWNER +.. c:macro:: NTSYNC_IOC_MUTEX_KILL Mark a mutex as unowned and abandoned if it is owned by the given owner. Takes an input-only pointer to a 32-bit integer denoting the @@ -276,11 +276,12 @@ The ioctls on the individual objects are as follows: * - ``timeout`` - Absolute timeout in nanoseconds. If ``NTSYNC_WAIT_REALTIME`` is set, the timeout is measured against the REALTIME clock; - otherwise it is measured against the MONOTONIC clock. If the - timeout is equal to or earlier than the current time, the - function returns immediately without sleeping. If ``timeout`` - is U64_MAX, the function will sleep until an object is - signaled, and will not fail with ``ETIMEDOUT``. + otherwise it is measured against the MONOTONIC clock in the + caller's time namespace. If the timeout is equal to or earlier + than the current time, the function returns immediately + without sleeping. If ``timeout`` is U64_MAX, the function will + sleep until an object is signaled, and will not fail with + ``ETIMEDOUT``. * - ``objs`` - Pointer to an array of ``count`` file descriptors (specified as an integer so that the structure has the same -- 2.53.0

July 23, 2026

[PATCH v2 3/5] ntsync: reject wait ioctls with zero owner

by Elizabeth Figura

From: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> setup_wait() already validates pad and flags but not owner, while Documentation/userspace-api/ntsync.rst requires EINVAL when owner is zero. Reject early before queueing waiters. Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25(a)gmail.com> Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com> Signed-off-by: Elizabeth Figura <zfigura(a)codeweavers.com> --- drivers/misc/ntsync.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c index 02c9d1192812..4a805919bb0c 100644 --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -875,6 +875,9 @@ static int setup_wait(struct ntsync_device *dev, if (args->pad || (args->flags & ~NTSYNC_WAIT_REALTIME)) return -EINVAL; + if (!args->owner) + return -EINVAL; + if (size >= sizeof(fds)) return -EINVAL; -- 2.53.0

July 23, 2026