January 2022 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] winmm/tests: Demonstrate that WOM_DONE is not invoked reentrantly

by Marvin

Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=106200 Your paranoid android. === debian11 (32 bit Arabic:Morocco report) === winmm: wave.c:1644: Test succeeded inside todo block: callback called reentrantly

Jan. 27, 2022

Re: [RFC PATCH 1/6] server: Allow calling async_handoff() with status code STATUS_ALERTED.

by Alexandre Julliard

"Zebediah Figura (she/her)" <zfigura(a)codeweavers.com> writes: > On 1/27/22 06:02, Jacek Caban wrote: >> On 1/27/22 00:52, Zebediah Figura (she/her) wrote: >>> On 1/23/22 11:29, Jinoh Kang wrote: >>>> +static int async_add_queue( struct object *obj, struct >>>> wait_queue_entry *entry ) >>>> +{ >>>> + struct async *async = (struct async *)obj; >>>> + assert( obj->ops == &async_ops ); >>>> + >>>> + if (!async->pending && async->terminated && async->alerted) >>>> + { >>>> + /* The client has failed to complete synchronously >>>> (e.g. EWOULDBLOCK). >>>> + * Restart the async as fully fledged asynchronous I/O, where >>>> + * the completion port notification and APC call will be >>>> triggered >>>> + * appropriately. */ >>>> + async->pending = 1; >>>> + >>>> + /* Unset the signaled flag if the client wants to block >>>> on this async. */ >>>> + if (async->blocking) async->signaled = 0; >>>> + >>>> + async_set_result( obj, STATUS_PENDING, 0 ); /* kick it off */ >>>> + } >>>> + >>>> + return add_queue( obj, entry ); >>>> +} >>>> + >>> >>> I'll admit, this kind of thing is why I didn't really want to have >>> to try to optimize 3 server calls into 2. Asyncs are already really >>> complicated, in terms of the many paths they can take, and it seems >>> like no matter what we do they're going to get worse. >> >> Did you consider moving whole sock_send() and try_send() to server? >> We could then have a proper and reliable queue in server socket >> object and client could just do a regular generic server ioctl. (I >> didn't really follow closely the conversation, so sorry if I missed >> something). > > That's actually a good point, thanks for making it. I think I actually > did consider this when first moving things around, but decided against > it on the grounds of keeping stuff out of the server... > > Note that we do have to deal with scatter/gather, and the control and > address in recvmsg, so it can't quite do a generic ioctl, we'd still > need to use a special async I/O proc on the ntdll side. But it does > obviate the need to change the async infrastructure at all. > > One possible concern is that we'd end up doing a lot of large copies > over the server request sockets. It's not clear to me if that's > anything to worry about. I think that's a concern, yes. You'd also need large buffers on the server side. It would of course make some things easier, but I'm not sure it's a good idea. -- Alexandre Julliard julliard(a)winehq.org

Jan. 27, 2022

[PATCH 3/3] hidclass.sys: Add input.inf that matches all HID devices.

by Arkadiusz Hiler

This makes it so that all the devices on the HID bus now have Class, ClassGUID, Driver and DriverDesc register properties populated. Without having at least Driver and Class set SDL2 refuses to use HID devices directly. Signed-off-by: Arkadiusz Hiler <ahiler(a)codeweavers.com> --- dlls/hidclass.sys/Makefile.in | 2 ++ dlls/hidclass.sys/hidclass.rc | 20 ++++++++++++++++++++ dlls/hidclass.sys/input.inf | 13 +++++++++++++ loader/wine.inf.in | 1 + 4 files changed, 36 insertions(+) create mode 100644 dlls/hidclass.sys/hidclass.rc create mode 100644 dlls/hidclass.sys/input.inf diff --git a/dlls/hidclass.sys/Makefile.in b/dlls/hidclass.sys/Makefile.in index 25a0396dabe..788828ad66a 100644 --- a/dlls/hidclass.sys/Makefile.in +++ b/dlls/hidclass.sys/Makefile.in @@ -5,3 +5,5 @@ IMPORTS = hal ntoskrnl user32 hidparse C_SRCS = \ device.c \ pnp.c + +RC_SRCS = hidclass.rc diff --git a/dlls/hidclass.sys/hidclass.rc b/dlls/hidclass.sys/hidclass.rc new file mode 100644 index 00000000000..409bdc16b45 --- /dev/null +++ b/dlls/hidclass.sys/hidclass.rc @@ -0,0 +1,20 @@ +/* + * Copyright 2022 Arkadiusz Hiler + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +/* @makedep: input.inf */ +1 WINE_DATA_FILE input.inf diff --git a/dlls/hidclass.sys/input.inf b/dlls/hidclass.sys/input.inf new file mode 100644 index 00000000000..d9222b13672 --- /dev/null +++ b/dlls/hidclass.sys/input.inf @@ -0,0 +1,13 @@ +[Version] +Signature="$CHICAGO$" +ClassGuid={745a17a0-74d3-11d0-b6fe-00a0c90f57da} +Class=HIDClass + +[Manufacturer] +Wine=mfg_section + +[mfg_section] +Wine HID device=device_section,HID\ + +[device_section.Services] +AddService = ,0x2 diff --git a/loader/wine.inf.in b/loader/wine.inf.in index c0251934dfc..afa344ffa80 100644 --- a/loader/wine.inf.in +++ b/loader/wine.inf.in @@ -5717,6 +5717,7 @@ protocol,"@%11%\ws2_32.dll,-3" services,"@%11%\ws2_32.dll,-4" [InfFiles] +input.inf,"@%12%\hidclass.sys,-1" winebus.inf,"@%12%\winebus.sys,-1" winehid.inf,"@%12%\winehid.sys,-1" wineusb.inf,"@%12%\wineusb.sys,-1" -- 2.35.0

Jan. 27, 2022

[PATCH 2/3] winebus.sys: Process quirky DualSense bluetooth reports.

by Arkadiusz Hiler

Signed-off-by: Arkadiusz Hiler <ahiler(a)codeweavers.com> --- dlls/winebus.sys/bus_udev.c | 40 +++++++++++++++++++++++++++++++++ dlls/winebus.sys/unix_private.h | 1 + dlls/winebus.sys/unixlib.c | 6 +++++ 3 files changed, 47 insertions(+) diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c index 4bd0907fdfd..c6185adf23d 100644 --- a/dlls/winebus.sys/bus_udev.c +++ b/dlls/winebus.sys/bus_udev.c @@ -117,6 +117,7 @@ static inline struct base_device *impl_from_unix_device(struct unix_device *ifac } #define QUIRK_DS4_BT 0x1 +#define QUIRK_DUALSENSE_BT 0x2 struct hidraw_device { @@ -356,6 +357,36 @@ static void hidraw_device_read_report(struct unix_device *iface) buff[0] = 1; } + /* The behavior of DualSense is very similar to DS4 described above with a few exceptions. + * + * The report number #41 is used for the extended bluetooth input report. The report comes + * with only one extra byte in front and the format is not exactly the same as the one used + * for the report #1 so we need to shuffle a few bytes around. + * + * Basic #1 report: + * X Y Z RZ Buttons[3] TriggerLeft TriggerRight + * + * Extended #41 report: + * Prefix X Y Z Rz TriggerLeft TriggerRight Counter Buttons[3] ... + */ + if ((impl->quirks & QUIRK_DUALSENSE_BT) && report_buffer[0] == 0x31 && size >= 11) + { + BYTE trigger[2]; + size = 10; + buff += 1; + + buff[0] = 1; /* fake report #1 */ + + trigger[0] = buff[5]; /* TriggerLeft*/ + trigger[1] = buff[6]; /* TriggerRight */ + + buff[5] = buff[8]; /* Buttons[0] */ + buff[6] = buff[9]; /* Buttons[1] */ + buff[7] = buff[10]; /* Buttons[2] */ + buff[8] = trigger[0]; /* TriggerLeft */ + buff[9] = trigger[1]; /* TirggerRight */ + } + bus_event_queue_input_report(&event_queue, iface, buff, size); } } @@ -373,6 +404,12 @@ static void hidraw_disable_sony_quirks(struct unix_device *iface) TRACE("Disabling report quirk for Bluetooth DualShock4 controller iface %p\n", iface); impl->quirks &= ~QUIRK_DS4_BT; } + + if ((impl->quirks & QUIRK_DUALSENSE_BT)) + { + TRACE("Disabling report quirk for Bluetooth DualSense controller iface %p\n", iface); + impl->quirks &= ~QUIRK_DUALSENSE_BT; + } } static void hidraw_device_set_output_report(struct unix_device *iface, HID_XFER_PACKET *packet, IO_STATUS_BLOCK *io) @@ -1219,6 +1256,9 @@ static void hidraw_set_quirks(struct hidraw_device *impl, DWORD bus_type, WORD v { if (bus_type == BUS_BLUETOOTH && is_dualshock4_gamepad(vid, pid)) impl->quirks |= QUIRK_DS4_BT; + + if (bus_type == BUS_BLUETOOTH && is_dualsense_gamepad(vid, pid)) + impl->quirks |= QUIRK_DUALSENSE_BT; } static void udev_add_device(struct udev_device *dev, int fd) diff --git a/dlls/winebus.sys/unix_private.h b/dlls/winebus.sys/unix_private.h index efecf6cdbe3..e897251dea8 100644 --- a/dlls/winebus.sys/unix_private.h +++ b/dlls/winebus.sys/unix_private.h @@ -266,5 +266,6 @@ extern void hid_device_set_effect_state(struct unix_device *iface, BYTE index, B BOOL is_xbox_gamepad(WORD vid, WORD pid) DECLSPEC_HIDDEN; BOOL is_dualshock4_gamepad(WORD vid, WORD pid) DECLSPEC_HIDDEN; +BOOL is_dualsense_gamepad(WORD vid, WORD pid) DECLSPEC_HIDDEN; #endif /* __WINEBUS_UNIX_PRIVATE_H */ diff --git a/dlls/winebus.sys/unixlib.c b/dlls/winebus.sys/unixlib.c index 1269ae05c2b..3a7c3a16428 100644 --- a/dlls/winebus.sys/unixlib.c +++ b/dlls/winebus.sys/unixlib.c @@ -70,6 +70,12 @@ BOOL is_dualshock4_gamepad(WORD vid, WORD pid) return FALSE; } +BOOL is_dualsense_gamepad(WORD vid, WORD pid) +{ + if (vid == 0x054c && pid == 0x0ce6) return TRUE; + return FALSE; +} + struct mouse_device { struct unix_device unix_device; -- 2.35.0

Jan. 27, 2022

[PATCH 1/3] winebus.sys: Enable extended BT reports for DualShock 4 controllers when requested.

by Arkadiusz Hiler

This happens if any of the vendor-specific reports is used. SDL triggers the mode switch when calling SDL_GameControllerSetSensorEnabled() on supported devices. This is a one-way transition, i.e. cannot be undone without restarting the controller, so it's fine to have it tied to lifetime of winebus. Signed-off-by: Arkadiusz Hiler <ahiler(a)codeweavers.com> --- dlls/winebus.sys/bus_udev.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c index 2269f5b904e..4bd0907fdfd 100644 --- a/dlls/winebus.sys/bus_udev.c +++ b/dlls/winebus.sys/bus_udev.c @@ -360,6 +360,21 @@ static void hidraw_device_read_report(struct unix_device *iface) } } +static void hidraw_disable_sony_quirks(struct unix_device *iface) +{ + struct hidraw_device *impl = hidraw_impl_from_unix_device(iface); + + /* FIXME: we may want to validate CRC at the end of the outbound HID reports, + * as controllers do not switch modes if it is incorrect. + */ + + if ((impl->quirks & QUIRK_DS4_BT)) + { + TRACE("Disabling report quirk for Bluetooth DualShock4 controller iface %p\n", iface); + impl->quirks &= ~QUIRK_DS4_BT; + } +} + static void hidraw_device_set_output_report(struct unix_device *iface, HID_XFER_PACKET *packet, IO_STATUS_BLOCK *io) { struct hidraw_device *impl = hidraw_impl_from_unix_device(iface); @@ -379,6 +394,7 @@ static void hidraw_device_set_output_report(struct unix_device *iface, HID_XFER_ if (count > 0) { + hidraw_disable_sony_quirks(iface); io->Information = count; io->Status = STATUS_SUCCESS; } @@ -411,6 +427,7 @@ static void hidraw_device_get_feature_report(struct unix_device *iface, HID_XFER if (count > 0) { + hidraw_disable_sony_quirks(iface); io->Information = count; io->Status = STATUS_SUCCESS; } @@ -447,6 +464,7 @@ static void hidraw_device_set_feature_report(struct unix_device *iface, HID_XFER if (count > 0) { + hidraw_disable_sony_quirks(iface); io->Information = count; io->Status = STATUS_SUCCESS; } -- 2.35.0

Jan. 27, 2022

Re: [PATCH 1/3] wined3d: Handle discarded buffers in buffer_resource_sub_resource_map().

by Zebediah Figura (she/her)

On 1/27/22 07:13, Henri Verbeet wrote: >>> What is the issue exactly? Is it that buffer->buffer_object may not >>> have been created yet for discarded resources? >> >> More generally, no location may yet have been prepared. In particular >> after patch 3/3 no location will be prepared on creation. > > It probably makes sense to check for WINED3D_BUFFER_USE_BO instead of > buffer->buffer_object then, and add wined3d_buffer_prepare_location() > calls to paths that don't already call wined3d_buffer_load_location(). Sure, that makes sense.

Jan. 27, 2022

Re: [RFC PATCH 1/6] server: Allow calling async_handoff() with status code STATUS_ALERTED.

by Zebediah Figura (she/her)

On 1/27/22 06:02, Jacek Caban wrote: > On 1/27/22 00:52, Zebediah Figura (she/her) wrote: >> On 1/23/22 11:29, Jinoh Kang wrote: >>> +static int async_add_queue( struct object *obj, struct >>> wait_queue_entry *entry ) >>> +{ >>> + struct async *async = (struct async *)obj; >>> + assert( obj->ops == &async_ops ); >>> + >>> + if (!async->pending && async->terminated && async->alerted) >>> + { >>> + /* The client has failed to complete synchronously (e.g. >>> EWOULDBLOCK). >>> + * Restart the async as fully fledged asynchronous I/O, where >>> + * the completion port notification and APC call will be >>> triggered >>> + * appropriately. */ >>> + async->pending = 1; >>> + >>> + /* Unset the signaled flag if the client wants to block on >>> this async. */ >>> + if (async->blocking) async->signaled = 0; >>> + >>> + async_set_result( obj, STATUS_PENDING, 0 ); /* kick it off */ >>> + } >>> + >>> + return add_queue( obj, entry ); >>> +} >>> + >> >> I'll admit, this kind of thing is why I didn't really want to have to >> try to optimize 3 server calls into 2. Asyncs are already really >> complicated, in terms of the many paths they can take, and it seems >> like no matter what we do they're going to get worse. > > > Did you consider moving whole sock_send() and try_send() to server? We > could then have a proper and reliable queue in server socket object and > client could just do a regular generic server ioctl. (I didn't really > follow closely the conversation, so sorry if I missed something). That's actually a good point, thanks for making it. I think I actually did consider this when first moving things around, but decided against it on the grounds of keeping stuff out of the server... Note that we do have to deal with scatter/gather, and the control and address in recvmsg, so it can't quite do a generic ioctl, we'd still need to use a special async I/O proc on the ntdll side. But it does obviate the need to change the async infrastructure at all. One possible concern is that we'd end up doing a lot of large copies over the server request sockets. It's not clear to me if that's anything to worry about.

Jan. 27, 2022

Re: [PATCH] ws2_32: Increased MAX_SOCKETS_PER_PROCESS to 256

by Andrew Miskell

Based on the documentation from Microsoft, modern versions of Windows use Windows Socket version 2.2. This particular parameter which sets the value of iMaxSockets is only used in the Windows Socket 1.0/1.1 implementations and is/should be ignored in all 2.x implementations, which may explain why you’re not seeing this in modern Windows versions. I’ve resubmitted a patch to remove the define and replace the variable used for iMaxSockets.

Jan. 27, 2022

[PATCH] ws2_32: Increased iMaxSockets to 256

by Andrew Miskell

Removed define for MAX_SOCKETS_PER_PROCESS and hardcoded value to iMaxSockets Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50352 Signed-off-by: Andrew Miskell <andrewmiskell(a)mac.com> --- dlls/ws2_32/socket.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c index fe7e4fb3464..f820291c117 100644 --- a/dlls/ws2_32/socket.c +++ b/dlls/ws2_32/socket.c @@ -419,7 +419,6 @@ static BOOL socket_list_remove( SOCKET socket ) return FALSE; } -#define MAX_SOCKETS_PER_PROCESS 128 /* reasonable guess */ #define MAX_UDP_DATAGRAM 1024 static INT WINAPI WSA_DefaultBlockingHook( FARPROC x ); @@ -589,7 +588,7 @@ int WINAPI WSAStartup(WORD wVersionRequested, LPWSADATA lpWSAData) lpWSAData->wHighVersion = 0x0202; strcpy(lpWSAData->szDescription, "WinSock 2.0" ); strcpy(lpWSAData->szSystemStatus, "Running" ); - lpWSAData->iMaxSockets = MAX_SOCKETS_PER_PROCESS; + lpWSAData->iMaxSockets = 256; lpWSAData->iMaxUdpDg = MAX_UDP_DATAGRAM; /* don't do anything with lpWSAData->lpVendorInfo */ /* (some apps don't allocate the space for this field) */ -- 2.30.1 (Apple Git-130)

Jan. 27, 2022

[PATCH v2 6/6] msvcp140_atomic_wait: Implement __std_bulk_submit_threadpool_work.

by Daniel Lehman

v2 - remove racy test

Jan. 27, 2022