March 2025 - Wine-Devel - list.winehq.org

Wine staging 10.4 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 10.4 (341 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * d3dx9: Implement d3dx_effect_SetRawValue. * d3dx9/tests: Implement tests for d3dx_effect_SetRawValue(). * winex11.drv: Don't use MWM_DECOR_RESIZEH, window resizing is controlled by MWM_FUNC_RESIZE. * winex11.drv: Don't add MWM_DECOR_BORDER to windows without a caption. * winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow. Removed (No longer required). * None Added: * msxml3: Correct regression when looping element properties. Updated: * vkd3d-latest * Staging 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.

March 22, 2025

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all

by Elizabeth Figura

On Saturday, 15 March 2025 04:39:46 CDT Dan Carpenter wrote: > On Fri, Mar 14, 2025 at 05:13:50PM -0500, Elizabeth Figura wrote: > > On Friday, 14 March 2025 05:14:30 CDT Su Hui wrote: > > > On 2025/3/14 17:21, Dan Carpenter wrote: > > > > On Fri, Mar 14, 2025 at 03:14:51PM +0800, Su Hui wrote: > > > >> When 'manual=false' and 'signaled=true', then expected value when using > > > >> NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > > > >> > > > >> Signed-off-by: Su Hui<suhui(a)nfschina.com> > > > >> --- > > > >> tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > >> > > > >> diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> index 3aad311574c4..bfb6fad653d0 100644 > > > >> --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > > > >> @@ -968,7 +968,7 @@ TEST(wake_all) > > > >> auto_event_args.manual = false; > > > >> auto_event_args.signaled = true; > > > >> objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > > > >> - EXPECT_EQ(0, objs[3]); > > > >> + EXPECT_LE(0, objs[3]); > > > > It's kind of weird how these macros put the constant on the left. > > > > It returns an "fd" on success. So this look reasonable. It probably > > > > won't return the zero fd so we could probably check EXPECT_LT()? > > > Agreed, there are about 29 items that can be changed to EXPECT_LT(). > > > I can send a v2 patchset with this change if there is no more other > > > suggestions. > > > > I personally think it looks wrong to use EXPECT_LT(), but I'll certainly > > defer to a higher maintainer on this point. > > I'm not sure I understand what you are saying. Are you saying that we > should allow zero as an expected file descriptor here? I don't have > strong feelings about that either way. Yes, my apologies for the ambiguous wording. That is, EXPECT_LE looks more correct to me than EXPECT_LT per se. > Putting variables on the right, Yoda speak is. Unnatural is. Yes, I certainly agree with this. I wrote it this way in the first place because I was following some other example, I forget which. > I did a git grep and the KUNIT_EXPECT_LT() just calls the parameters > left and right instead of "expected" and "seen". Expected is wrong > for LT because we expect it to be != to the expected value. It's > the opposite. We're expecting the unexpected! It would be better > to just call them left and right. > > regards, > dan carpenter >

March 15, 2025

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all

by Elizabeth Figura

On Friday, 14 March 2025 05:14:30 CDT Su Hui wrote: > On 2025/3/14 17:21, Dan Carpenter wrote: > > On Fri, Mar 14, 2025 at 03:14:51PM +0800, Su Hui wrote: > >> When 'manual=false' and 'signaled=true', then expected value when using > >> NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > >> > >> Signed-off-by: Su Hui<suhui(a)nfschina.com> > >> --- > >> tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > >> index 3aad311574c4..bfb6fad653d0 100644 > >> --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > >> +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > >> @@ -968,7 +968,7 @@ TEST(wake_all) > >> auto_event_args.manual = false; > >> auto_event_args.signaled = true; > >> objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > >> - EXPECT_EQ(0, objs[3]); > >> + EXPECT_LE(0, objs[3]); > > It's kind of weird how these macros put the constant on the left. > > It returns an "fd" on success. So this look reasonable. It probably > > won't return the zero fd so we could probably check EXPECT_LT()? > Agreed, there are about 29 items that can be changed to EXPECT_LT(). > I can send a v2 patchset with this change if there is no more other > suggestions. I personally think it looks wrong to use EXPECT_LT(), but I'll certainly defer to a higher maintainer on this point.

March 14, 2025

Re: [PATCH 4/4] docs: ntsync: update NTSYNC_IOC_*

by Elizabeth Figura

On Friday, 14 March 2025 02:14:54 CDT Su Hui wrote: > Some macros in the document do not match the code and the header files, > correct these macros according to the definitions in the code. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > Documentation/userspace-api/ntsync.rst | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/Documentation/userspace-api/ntsync.rst b/Documentation/userspace-api/ntsync.rst > index 25e7c4aef968..969774bf4c60 100644 > --- a/Documentation/userspace-api/ntsync.rst > +++ b/Documentation/userspace-api/ntsync.rst > @@ -152,9 +152,9 @@ 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, > + Release 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 > output contains its previous count. > > @@ -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 > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

March 14, 2025

Re: [PATCH 3/4] selftests: ntsync: update config

by Elizabeth Figura

On Friday, 14 March 2025 02:14:53 CDT Su Hui wrote: > ntsync should be tested when CONFIG_NTSYNC is setting rather than > CONFIG_WINESYNC, correct this. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/config | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/config b/tools/testing/selftests/drivers/ntsync/config > index 60539c826d06..0aa68de147af 100644 > --- a/tools/testing/selftests/drivers/ntsync/config > +++ b/tools/testing/selftests/drivers/ntsync/config > @@ -1 +1 @@ > -CONFIG_WINESYNC=y > +CONFIG_NTSYNC=y > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

March 14, 2025

Re: [PATCH 2/4] selftests: ntsync: avoid possible overflow in 32-bit machine

by Elizabeth Figura

On Friday, 14 March 2025 02:14:52 CDT Su Hui wrote: > When using '-m32' flag to compile this test with gcc, there are some > errors when running test: > > ntsync.c:785:wake_any:Expected ETIMEDOUT (110) == ret (0) > ntsync.c:823:wake_any:Expected (1) (1) == __count (0) > ... > FAILED: 7 / 11 tests passed. > Totals: pass:7 fail:4 xfail:0 xpass:0 skip:0 error:0 > > There is an overflow about 'timeout'. 'timespec->tv_sec' is 4 bytes in > 32-bit machine. And 'timeout.tv_sec * 1000000000' causing the overflow > problem, adding a cast to avoid this problem. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/ntsync.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > index bfb6fad653d0..ded83dc58e6b 100644 > --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > @@ -103,7 +103,7 @@ static int wait_objs(int fd, unsigned long request, __u32 count, > > clock_gettime(CLOCK_MONOTONIC, &timeout); > > - args.timeout = timeout.tv_sec * 1000000000 + timeout.tv_nsec; > + args.timeout = (__u64)timeout.tv_sec * 1000000000 + timeout.tv_nsec; > args.count = count; > args.objs = (uintptr_t)objs; > args.owner = owner; > @@ -729,7 +729,7 @@ static __u64 get_abs_timeout(unsigned int ms) > { > struct timespec timeout; > clock_gettime(CLOCK_MONOTONIC, &timeout); > - return (timeout.tv_sec * 1000000000) + timeout.tv_nsec + (ms * 1000000); > + return ((__u64)timeout.tv_sec * 1000000000) + timeout.tv_nsec + (ms * 1000000); > } > > static int wait_for_thread(pthread_t thread, unsigned int ms) > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

March 14, 2025

Re: [PATCH 1/4] selftests: ntsync: fix the wrong condition in wake_all

by Elizabeth Figura

On Friday, 14 March 2025 02:14:51 CDT Su Hui wrote: > When 'manual=false' and 'signaled=true', then expected value when using > NTSYNC_IOC_CREATE_EVENT should be greater than zero. Fix this typo error. > > Signed-off-by: Su Hui <suhui(a)nfschina.com> > --- > tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/drivers/ntsync/ntsync.c b/tools/testing/selftests/drivers/ntsync/ntsync.c > index 3aad311574c4..bfb6fad653d0 100644 > --- a/tools/testing/selftests/drivers/ntsync/ntsync.c > +++ b/tools/testing/selftests/drivers/ntsync/ntsync.c > @@ -968,7 +968,7 @@ TEST(wake_all) > auto_event_args.manual = false; > auto_event_args.signaled = true; > objs[3] = ioctl(fd, NTSYNC_IOC_CREATE_EVENT, &auto_event_args); > - EXPECT_EQ(0, objs[3]); > + EXPECT_LE(0, objs[3]); > > wait_args.timeout = get_abs_timeout(1000); > wait_args.objs = (uintptr_t)objs; > Reviewed-by: Elizabeth Figura <zfigura(a)codeweavers.com>

March 14, 2025

Re: Testbot since the weekend not reachable

by Bernhard Übelacker

Short addition: Temporarily increasing my Firefox settings network.http.connection-timeout and network.http.tls-handshake-timeout makes the overview page load after several minutes. Probably deleting these 5900 "[wine-devel]" queued jobs might get Testbot back to normal operation? Kind regards, Bernhard Am 11.03.25 um 11:20 schrieb Ziqing Hui: > I can't access testbot either. > > On 3/11/25 17:47, Bernhard Übelacker wrote: >> Hello, >> is someone else also experiencing issues when accessing testbot.winehq.org? >> This seems to have caused missing results for the Friday tests run. >> >> Today in my browser still no results get shown. >> >> Querying via wget it shows data gets delivered after 3 minutes. >> The resulting page looks like at Friday got 5900 jobs queued (151728 to 157632). >> These jobs are all prefixed with [wine-devel], like if there >> was a jam in the patch submission? >> >> Kind regards, >> Bernhard >> >> >> $ LANG=C wget -O testbot.html https://testbot.winehq.org/ 2>&1 | ts '%Y-%m-%d %H:%M:%S:' >> 2025-03-11 09:55:15: --2025-03-11 09:55:15-- https://testbot.winehq.org/ >> 2025-03-11 09:55:15: Resolving testbot.winehq.org (testbot.winehq.org) 104.130.219.87, 2001:4801:7828:101:be76:4eff:fe10:1727 >> 2025-03-11 09:56:20: Connecting to testbot.winehq.org (testbot.winehq.org)|104.130.219.87|:443... connected. >> 2025-03-11 09:58:00: HTTP request sent, awaiting response... 200 OK >> 2025-03-11 09:58:00: Length: unspecified [text/html] >> 2025-03-11 09:58:00: Saving to: 'testbot.html' >> 2025-03-11 09:58:00: >> 2025-03-11 09:58:00: 0K .......... .......... .......... .......... .......... 187K >> 2025-03-11 09:58:00: 50K .......... .......... .......... .......... .......... 236K >> ... >> 2025-03-11 09:58:11: 2350K .......... .......... .......... .......... .......... 349K >> 2025-03-11 09:58:13: 2400K .......... .......... 8.99K=13s >> 2025-03-11 09:58:13: >> 2025-03-11 09:58:13: 2025-03-11 09:58:13 (188 KB/s) - 'testbot.html' saved [2478249] >> 2025-03-11 09:58:13: >> >> > >

March 11, 2025

Re: Powrprof patches

by robert lippmann

Some more follow up questions: The registry keys are initially created during Windows installation. So, I would add them to wine.inf.in. When is this run? Every boot where wine.inf changes? Hard to tell from the docs. If so, and I set a default power profile (it’s just a value in the registry key), will it get overwritten? Also, the existing code puts semaphores around registry access for some reason (it is 20 year old code). I assume that is no longer necessary? Thanks, Rob

March 11, 2025

Re: Testbot since the weekend not reachable

by Ziqing Hui

I can't access testbot either. On 3/11/25 17:47, Bernhard Übelacker wrote: > Hello, > is someone else also experiencing issues when accessing testbot.winehq.org? > This seems to have caused missing results for the Friday tests run. > > Today in my browser still no results get shown. > > Querying via wget it shows data gets delivered after 3 minutes. > The resulting page looks like at Friday got 5900 jobs queued (151728 to 157632). > These jobs are all prefixed with [wine-devel], like if there > was a jam in the patch submission? > > Kind regards, > Bernhard > > > $ LANG=C wget -O testbot.html https://testbot.winehq.org/ 2>&1 | ts '%Y-%m-%d %H:%M:%S:' > 2025-03-11 09:55:15: --2025-03-11 09:55:15-- https://testbot.winehq.org/ > 2025-03-11 09:55:15: Resolving testbot.winehq.org (testbot.winehq.org) 104.130.219.87, 2001:4801:7828:101:be76:4eff:fe10:1727 > 2025-03-11 09:56:20: Connecting to testbot.winehq.org (testbot.winehq.org)|104.130.219.87|:443... connected. > 2025-03-11 09:58:00: HTTP request sent, awaiting response... 200 OK > 2025-03-11 09:58:00: Length: unspecified [text/html] > 2025-03-11 09:58:00: Saving to: 'testbot.html' > 2025-03-11 09:58:00: > 2025-03-11 09:58:00: 0K .......... .......... .......... .......... .......... 187K > 2025-03-11 09:58:00: 50K .......... .......... .......... .......... .......... 236K > ... > 2025-03-11 09:58:11: 2350K .......... .......... .......... .......... .......... 349K > 2025-03-11 09:58:13: 2400K .......... .......... 8.99K=13s > 2025-03-11 09:58:13: > 2025-03-11 09:58:13: 2025-03-11 09:58:13 (188 KB/s) - 'testbot.html' saved [2478249] > 2025-03-11 09:58:13: > >

March 11, 2025