October 2016 - Wine-Devel - list.winehq.org

Re: kernel32: Improved GetUserPreferredUILanguages stub.
by Marvin Oct. 18, 2016

Oct. 18, 2016

Hi, While running your changed tests on Windows, 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=26212 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH v2 2/2] hid/tests: Add HID device enumeration test
by Sebastian Lackner Oct. 18, 2016

Oct. 18, 2016

On 17.10.2016 15:58, Aric Stewart wrote: > v2: Suggestions from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > configure | 1 + > configure.ac | 1 + > dlls/hid/tests/Makefile.in | 5 +++ > dlls/hid/tests/device.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 89 insertions(+) > create mode 100644 dlls/hid/tests/Makefile.in > create mode 100644 dlls/hid/tests/device.c > > > > v2-0002-hid-tests-Add-HID-device-enumeration-test.txt > > > diff --git a/configure b/configure > index c21bda3..b397b38 100755 > --- a/configure > +++ b/configure > @@ -17940,6 +17940,7 @@ wine_fn_config_dll gpkcsp enable_gpkcsp > wine_fn_config_dll hal enable_hal > wine_fn_config_dll hhctrl.ocx enable_hhctrl_ocx clean,implib htmlhelp > wine_fn_config_dll hid enable_hid implib > +wine_fn_config_test dlls/hid/tests hid_test > wine_fn_config_dll hidclass.sys enable_hidclass_sys implib hidclass > wine_fn_config_dll hlink enable_hlink clean,implib > wine_fn_config_test dlls/hlink/tests hlink_test > diff --git a/configure.ac b/configure.ac > index c624c9e..40060b7 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -3027,6 +3027,7 @@ WINE_CONFIG_DLL(gpkcsp) > WINE_CONFIG_DLL(hal) > WINE_CONFIG_DLL(hhctrl.ocx,,[clean,implib],[htmlhelp]) > WINE_CONFIG_DLL(hid,,[implib]) > +WINE_CONFIG_TEST(dlls/hid/tests) > WINE_CONFIG_DLL(hidclass.sys,,[implib],[hidclass]) > WINE_CONFIG_DLL(hlink,,[clean,implib]) > WINE_CONFIG_TEST(dlls/hlink/tests) > diff --git a/dlls/hid/tests/Makefile.in b/dlls/hid/tests/Makefile.in > new file mode 100644 > index 0000000..6bf3773 > --- /dev/null > +++ b/dlls/hid/tests/Makefile.in > @@ -0,0 +1,5 @@ > +TESTDLL = hid.dll > +IMPORTS = hid setupapi > + > +C_SRCS = \ > + device.c > diff --git a/dlls/hid/tests/device.c b/dlls/hid/tests/device.c > new file mode 100644 > index 0000000..47ad1a3 > --- /dev/null > +++ b/dlls/hid/tests/device.c > @@ -0,0 +1,82 @@ > +/* > + * Copyright (c) 2016 Aric Stewart > + * > + * 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 > + */ > + > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windows.h" > +#include "setupapi.h" > +#include "ddk/hidsdi.h" > + > +#include "wine/test.h" > + > +static void enumerate_devices(void) I didn't point this out earlier, but usually test functions start with "test_". An exception would be if you plan to use this as a helper function to run other tests for all enumerated devices. Then you could either move most of the code to START_TEST, for example: --- snip --- START_TEST(device) { ... enumeration code ... test_device_info(file); ... enumeration code ... } --- snip --- or rename it to something like "run_for_each_device(callback)" and use a callback-based approach: --- snip --- START_TEST(device) { run_for_each_device(test_device_info); } --- snip --- > +{ > + GUID hid_guid; > + WCHAR device_name[128]; > + HDEVINFO info_set; > + DWORD index = 0; > + SP_DEVICE_INTERFACE_DATA interface_data; > + DWORD detail_size = MAX_PATH * sizeof(WCHAR); > + SP_DEVICE_INTERFACE_DETAIL_DATA_W *data; > + > + HidD_GetHidGuid(&hid_guid); > + > + ZeroMemory(&interface_data, sizeof(interface_data)); > + interface_data.cbSize = sizeof(interface_data); > + > + data = HeapAlloc(GetProcessHeap(), 0, sizeof(*data) + detail_size); > + data->cbSize = sizeof(*data); > + > + info_set = SetupDiGetClassDevsW(&hid_guid, NULL, NULL, DIGCF_DEVICEINTERFACE); > + while (SetupDiEnumDeviceInterfaces(info_set, NULL, &hid_guid, index, &interface_data)) > + { > + index ++; > + > + if (SetupDiGetDeviceInterfaceDetailW(info_set, &interface_data, data, sizeof(*data) + detail_size, NULL, NULL)) > + { > + NTSTATUS status; > + BOOL rc; > + PHIDP_PREPARSED_DATA ppd; > + HIDP_CAPS Caps; > + HANDLE file = CreateFileW(data->DevicePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); > + if (file == INVALID_HANDLE_VALUE) > + { > + trace("Failed to access device %s, likely not plugged in or access is denied.\n", wine_dbgstr_w(data->DevicePath)); > + continue; > + } > + rc = HidD_GetPreparsedData(file, &ppd); > + ok(rc, "Failed to get preparsed data(0x%x)\n", GetLastError()); > + status = HidP_GetCaps(ppd, &Caps); > + ok(status == HIDP_STATUS_SUCCESS, "Failed to get Caps(0x%x)\n", status); > + rc = HidD_GetProductString(file, device_name, sizeof(device_name)); > + ok(rc, "Failed to get product string(0x%x)\n", GetLastError()); > + trace("Found device %s (%s, %02x, %02x)\n", wine_dbgstr_w(device_name), wine_dbgstr_w(data->DevicePath), Caps.UsagePage, Caps.Usage); > + rc = HidD_FreePreparsedData(ppd); > + ok(rc, "Failed to free preparsed data(0x%x)\n", GetLastError()); > + CloseHandle(file); > + } > + } > + HeapFree(GetProcessHeap(), 0, data); > + if (info_set) > + SetupDiDestroyDeviceInfoList(info_set); According to MSDN SetupDiGetClassDevs returns INVALID_HANDLE_VALUE on failure, not NULL. If this check is not necessary you can also remove it. > +} > + > +START_TEST(device) > +{ > + enumerate_devices(); > +} > > >

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v5).
by Dmitry Timoshkov Oct. 18, 2016

Oct. 18, 2016

Roman Pišl <rpisl(a)seznam.cz> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. > > V5 - fixes failing test on Windows > > Based on https://www.winehq.org/pipermail/wine-patches/2016-July/151919.html > > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io> > Signed-off-by: Roman Pišl <rpisl(a)seznam.cz> Probably you shouldn't add someone's else sign-off without the author's agreement, or mention that you've got an explicit agreement from the patch author otherwise. > +#ifdef IPV6_V6ONLY > + if (unixaf == AF_INET6) > + { > + int enable = 1; > + int fd = get_sock_fd(ret, 0, NULL); > + setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &enable, sizeof(enable)); > + } > +#endif It's better to verify that get_sock_fd() succeded before using its result, and call release_sock_fd() at the end. -- Dmitry.

2 2

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v4).
by Bruno Jesus Oct. 17, 2016

Oct. 17, 2016

Hi, thanks for the retry. I'm not at home and I'm replying from mobile so I can't help much, from the test results it is clear that MS broke the API starting on Vista, the.tests need to be.enhaced so that they pass on both pré vista and post xp. In the sockets tests I have made that many times due to other API breaks, look for the word behavior around tests line 1760. So you can split and make tests pass on all systems. On Monday, October 17, 2016, Roman Pišl <rpisl(a)seznam.cz> wrote: > IP dual stack (v4+v6) should be disabled by default, but previous code > was setting IPV6_V6ONLY in bind() which prevented user to override it. > This patch moves setting IPV6_V6ONLY to socket creation time. > > Based on https://www.winehq.org/pipermail/wine-patches/2016- > July/151919.html > > Signed-off-by: Matthieu Nottale <matthieu.nottale(a)infinit.io > <javascript:;>> > Signed-off-by: Roman Pišl <rpisl(a)seznam.cz <javascript:;>> > --- > dlls/ws2_32/socket.c | 23 +++++++++------------- > dlls/ws2_32/tests/sock.c | 50 ++++++++++++++++++++++++++++++ > ++++++++++++++++-- > 2 files changed, 57 insertions(+), 16 deletions(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index e8c5130..d14e9d6 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -3240,20 +3240,6 @@ int WINAPI WS_bind(SOCKET s, const struct > WS_sockaddr* name, int namelen) > } > else > { > -#ifdef IPV6_V6ONLY > - const struct sockaddr_in6 *in6 = (const struct > sockaddr_in6*) &uaddr; > - if (name->sa_family == WS_AF_INET6 && > - !memcmp(&in6->sin6_addr, &in6addr_any, sizeof(struct > in6_addr))) > - { > - int enable = 1; > - if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, > &enable, sizeof(enable)) == -1) > - { > - release_sock_fd( s, fd ); > - SetLastError(WSAEAFNOSUPPORT); > - return SOCKET_ERROR; > - } > - } > -#endif > if (name->sa_family == WS_AF_INET) > { > struct sockaddr_in *in4 = (struct sockaddr_in*) > &uaddr; > @@ -7233,6 +7219,15 @@ SOCKET WINAPI WSASocketW(int af, int type, int > protocol, > TRACE("\tcreated %04lx\n", ret ); > if (ipxptype > 0) > set_ipx_packettype(ret, ipxptype); > + > +#ifdef IPV6_V6ONLY > + if (unixaf == AF_INET6) > + { > + int enable = 1; > + int fd = get_sock_fd(ret, 0, NULL); > + setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &enable, > sizeof(enable)); > + } > +#endif > return ret; > } > > diff --git a/dlls/ws2_32/tests/sock.c b/dlls/ws2_32/tests/sock.c > index a144bd3..a676255 100644 > --- a/dlls/ws2_32/tests/sock.c > +++ b/dlls/ws2_32/tests/sock.c > @@ -1732,7 +1732,7 @@ static void test_so_reuseaddr(void) > DWORD err; > > saddr.sin_family = AF_INET; > - saddr.sin_port = htons(9375); > + saddr.sin_port = htons(SERVERPORT+1); > saddr.sin_addr.s_addr = inet_addr("127.0.0.1"); > > s1=socket(AF_INET, SOCK_STREAM, 0); > @@ -6110,6 +6110,8 @@ static void test_ipv6only(void) > struct sockaddr_in sin4; > struct sockaddr_in6 sin6; > int ret; > + int enabled; > + int len; > > memset(&sin4, 0, sizeof(sin4)); > sin4.sin_family = AF_INET; > @@ -6142,6 +6144,50 @@ static void test_ipv6only(void) > ok(!ret, "Could not bind IPv4 address (LastError: %d; %d expected if > IPv6 binds to IPv4 as well).\n", > WSAGetLastError(), WSAEADDRINUSE); > > + closesocket(v4); > + closesocket(v6); > + v4 = INVALID_SOCKET; > + v6 = INVALID_SOCKET; > + > + /* Test again, this time disabling V6ONLY. */ > + sin4.sin_port = htons(SERVERPORT+2); > + sin6.sin6_port = htons(SERVERPORT+2); > + > + v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP); > + ok(v6 != INVALID_SOCKET, "Could not create IPv6 socket (LastError: > %d; %d expected if IPv6 not available).\n", > + WSAGetLastError(), WSAEAFNOSUPPORT); > + > + enabled = 2; > + len = sizeof(enabled); > + ret = getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, (char*)&enabled, > &len); > + if (ret) { > + skip("Could not check IPV6_V6ONLY (option not supported?) > ((LastError: %d).\n", WSAGetLastError()); > + goto end; > + } > + ok(enabled == 1, "IPV6_V6ONLY is not enabled by default.\n"); > + > + enabled = 0; > + ret = setsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, (char*)&enabled, len); > + ok(!ret, "Failed to disable IPV6_V6ONLY (LastError: %d).\n", > WSAGetLastError()); > + > + ret = bind(v6, (struct sockaddr*)&sin6, sizeof(sin6)); > + ok(!ret, "Could not bind IPv6 address (LastError: %d).\n", > WSAGetLastError()); > + > + enabled = 2; > + len = sizeof(enabled); > + getsockopt(v6, IPPROTO_IPV6, IPV6_V6ONLY, (char*)&enabled, &len); > + ok(enabled == 0, "IPV6_V6ONLY is enabled after bind.\n"); > + > + v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); > + ok(v4 != INVALID_SOCKET, "Could not create IPv4 socket (LastError: > %d).\n", > + WSAGetLastError()); > + > + WSASetLastError(0xdeadbeef); > + bind(v4, (struct sockaddr*)&sin4, sizeof(sin4)); > + > + ok(WSAGetLastError() == WSAEADDRINUSE, "Failed to disable IPV6_V6ONLY > (LastError: %d; %d expected if IPv6 binds to IPv4 as well).\n", > + WSAGetLastError(), WSAEADDRINUSE); > + > end: > if (v4 != INVALID_SOCKET) > closesocket(v4); > @@ -8024,7 +8070,7 @@ static void test_TransmitFile(void) > /* Setup a properly connected socket for transfers */ > memset(&bindAddress, 0, sizeof(bindAddress)); > bindAddress.sin_family = AF_INET; > - bindAddress.sin_port = htons(9375); > + bindAddress.sin_port = htons(SERVERPORT+1); > bindAddress.sin_addr.s_addr = inet_addr("127.0.0.1"); > iret = bind(server, (struct sockaddr*)&bindAddress, > sizeof(bindAddress)); > if (iret != 0) > -- > 2.7.3 > > > >

1 0

Re: [PATCH] ws2_32: Allow user to enable IP dual stack (v4).
by Marvin Oct. 17, 2016

Oct. 17, 2016

Hi, While running your changed tests on Windows, 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=26191 Your paranoid android. === wvistau64 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w2008s64 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w7u (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w7pro64 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). sock.c:7810: Test failed: bytesReturned isn't supposed to be 1 sock.c:7834: Test failed: GetOverlappedResult failed, error 0 === w8 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w864 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w1064 (32 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === wvistau64 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w2008s64 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: -559038737; 10048 expected if IPv6 binds to IPv4 as well). === w7pro64 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). sock.c:7810: Test failed: bytesReturned isn't supposed to be 1 sock.c:7856: Test failed: Waiting for timeout failed with 0 + errno 997 === w864 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well). === w1064 (64 bit sock) === sock.c:6188: Test failed: Failed to disable IPV6_V6ONLY (LastError: 0; 10048 expected if IPv6 binds to IPv4 as well).

1 0

Re: [PATCH v2] winebus.sys: Handle device reports for hidraw devices
by Sebastian Lackner Oct. 17, 2016

Oct. 17, 2016

On 17.10.2016 15:29, Aric Stewart wrote: > v2: Suggestions from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 3 ++ > dlls/winebus.sys/bus_udev.c | 73 ++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 123 +++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 198 insertions(+), 1 deletion(-) > > > > v2-0001-winebus.sys-Handle-device-reports-for-hidraw-device.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 7ce54bf..bcb1163 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -25,6 +25,8 @@ typedef struct > int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); > NTSTATUS (*get_string)(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length); > + NTSTATUS (*begin_report_processing)(DEVICE_OBJECT *device, BYTE **report_buffer, DWORD *buffer_length); > + void (*end_report_processing)(DEVICE_OBJECT *device, BYTE *report_buffer); > } platform_vtbl; > > void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > @@ -37,3 +39,4 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; > void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +void process_hid_report(DEVICE_OBJECT *device, const WCHAR *busidW, BYTE *report, DWORD length) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 243aabb..37c8412 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -61,6 +61,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > #ifdef HAVE_UDEV > > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > + > static struct udev *udev_context = NULL; > static DRIVER_OBJECT *udev_driver_obj = NULL; > > @@ -73,6 +75,11 @@ struct platform_private > { > struct udev_device *udev_device; > int device_fd; > + > + BYTE *report_buffer; > + int buffer_length; > + HANDLE report_thread; > + int control_pipe[2]; > }; > > static inline struct platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) > @@ -222,11 +229,77 @@ static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buf > return STATUS_SUCCESS; > } > > +static DWORD CALLBACK device_report_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + struct pollfd plfds[2]; > + > + plfds[0].fd = private->device_fd; > + plfds[0].events = POLLIN; > + plfds[0].revents = 0; > + plfds[1].fd = private->control_pipe[0]; > + plfds[1].events = POLLIN; > + plfds[1].revents = 0; > + > + while (1) > + { > + int size; > + if (poll(plfds, 2, -1) <= 0) continue; > + if (plfds[1].revents || !private->report_buffer || private->buffer_length == 0) > + break; > + size = read(plfds[0].fd, private->report_buffer, private->buffer_length); This could still cause problems when another thread copies the last_report while it is updated. I don't know how you are planning to implement it for other platforms, but wouldn't it be better to use a separate buffer in this thread, and let process_hid_report() do the copying? > + if (size == -1) > + TRACE_(hid_report)("Read failed. Likely an unplugged device\n"); > + else if (size == 0) > + TRACE_(hid_report)("Failed to read report\n"); > + else > + process_hid_report(device, hidraw_busidW, private->report_buffer, size); > + } > + return 0; > +} > + > +static NTSTATUS begin_report_processing(DEVICE_OBJECT *device, BYTE **buffer, DWORD *length) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + *length = private->buffer_length = 1024; > + *buffer = private->report_buffer = HeapAlloc(GetProcessHeap(), 0, *length); > + > + pipe(private->control_pipe); > + private->report_thread = CreateThread(NULL, 0, device_report_thread, device, 0, NULL); > + if (!private->report_thread) > + { > + ERR("Unable to create device report thread\n"); > + close(private->control_pipe[0]); > + close(private->control_pipe[1]); > + return STATUS_UNSUCCESSFUL; > + } > + else > + return STATUS_SUCCESS; > +} > + > +static void end_report_processing(DEVICE_OBJECT *device, BYTE *buffer) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + if (private->report_thread) > + { > + write(private->control_pipe[1], "q", 1); > + WaitForSingleObject(private->report_thread, INFINITE); > + close(private->control_pipe[0]); > + close(private->control_pipe[1]); > + } > + private->buffer_length = 0; > + private->report_buffer = NULL; > + HeapFree(GetProcessHeap(), 0, buffer); > +} > + > static const platform_vtbl hidraw_vtbl = > { > compare_platform_device, > hidraw_get_reportdescriptor, > hidraw_get_string, > + begin_report_processing, > + end_report_processing, > }; > > static void try_add_device(struct udev_device *dev) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 86adbf5..49dcc97 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -40,6 +40,7 @@ > #include "bus.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > struct pnp_device > { > @@ -58,6 +59,14 @@ struct device_extension > const WCHAR *busid; /* Expected to be a static constant */ > > const platform_vtbl *vtbl; > + > + BOOL processing_started; > + BYTE *last_report; > + DWORD last_report_size; > + DWORD buffer_size; > + LIST_ENTRY irp_queue; > + CRITICAL_SECTION report_cs; > + > BYTE platform_private[1]; > }; > > @@ -214,6 +223,9 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->busid = busidW; > ext->vtbl = vtbl; > > + InitializeListHead(&ext->irp_queue); > + InitializeCriticalSection(&ext->report_cs); You might want to give this CS a name, like done in other parts of wine. For example: --- snip --- InitializeCriticalSection(&src->lock); src->lock.DebugInfo->Spare[0] = (DWORD_PTR)(__FILE__ ": XA2SourceImpl.lock"); --- snip --- > + > /* add to list of pnp devices */ > pnp_dev->device = device; > list_add_tail(&pnp_devset, &pnp_dev->entry); > @@ -271,6 +283,8 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > { > struct device_extension *ext = (struct device_extension *)device->DeviceExtension; > struct pnp_device *pnp_device = ext->pnp_device; > + LIST_ENTRY *entry; > + IRP *irp; > > TRACE("(%p)\n", device); > > @@ -279,6 +293,23 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > LeaveCriticalSection(&device_list_cs); > > IoInvalidateDeviceRelations(device, RemovalRelations); > + > + if (ext->processing_started) > + ext->vtbl->end_report_processing(device, ext->last_report); > + > + /* Cancel pending IRPs */ > + EnterCriticalSection(&ext->report_cs); > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + irp->IoStatus.u.Status = STATUS_CANCELLED; > + irp->IoStatus.Information = 0; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + LeaveCriticalSection(&ext->report_cs); > + You will have to delete the CS here. Also make sure to reset Spare[0] if it was previously set to a debug string. For example: --- snip --- src->lock.DebugInfo->Spare[0] = 0; DeleteCriticalSection(&src->lock); --- snip --- > HeapFree(GetProcessHeap(), 0, ext->serial); > IoDeleteDevice(device); > > @@ -432,6 +463,58 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = (strlenW((WCHAR *)irp->UserBuffer) + 1) * sizeof(WCHAR); > break; > } > + case IOCTL_HID_GET_INPUT_REPORT: > + { > + HID_XFER_PACKET *packet = (HID_XFER_PACKET*)(irp->UserBuffer); > + TRACE_(hid_report)("IOCTL_HID_GET_INPUT_REPORT\n"); > + EnterCriticalSection(&ext->report_cs); > + if (!ext->processing_started) > + { > + irp->IoStatus.u.Status = status = ext->vtbl->begin_report_processing(device, &ext->last_report, &ext->buffer_size); > + if (status == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + { > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + } > + > + if (packet->reportBufferLen < ext->last_report_size) > + { > + irp->IoStatus.u.Status = status = STATUS_BUFFER_TOO_SMALL; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + > + ZeroMemory(packet->reportBuffer, packet->reportBufferLen); Do we need this line? Usually callers do not expect valid data after the length provided by irp->IoStatus.Information. Is it different in this case? > + memcpy(packet->reportBuffer, ext->last_report, ext->last_report_size); > + packet->reportBufferLen = ext->last_report_size; > + irp->IoStatus.Information = ext->last_report_size; > + irp->IoStatus.u.Status = status = STATUS_SUCCESS; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + case IOCTL_HID_READ_REPORT: > + { > + TRACE_(hid_report)("IOCTL_HID_READ_REPORT\n"); > + EnterCriticalSection(&ext->report_cs); > + if (!ext->processing_started) > + { > + if (ext->vtbl->begin_report_processing(device, &ext->last_report, &ext->buffer_size) == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + { > + irp->IoStatus.u.Status = status; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > + } > + InsertTailList(&ext->irp_queue, &irp->Tail.Overlay.ListEntry); > + status = STATUS_PENDING; > + LeaveCriticalSection(&ext->report_cs); > + break; > + } > default: > { > ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > @@ -441,11 +524,49 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > } > } > > - IoCompleteRequest(irp, IO_NO_INCREMENT); > + if (status != STATUS_PENDING) > + IoCompleteRequest(irp, IO_NO_INCREMENT); > > return status; > } > > +void process_hid_report(DEVICE_OBJECT *device, const WCHAR *busidW, BYTE *report, DWORD length) > +{ > + struct device_extension *ext = (struct device_extension*)device->DeviceExtension; > + IRP *irp; > + LIST_ENTRY *entry; > + > + EnterCriticalSection(&ext->report_cs); > + if (ext->last_report && report != ext->last_report && ext->buffer_size <= length) Shouldn't it be "length <= ext->buffer_size" ? > + { > + memcpy(ext->last_report, report, length); > + ext->last_report_size = length; > + } > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + IO_STACK_LOCATION *irpsp; > + TRACE_(hid_report)("Processing Request\n"); > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + irpsp = IoGetCurrentIrpStackLocation(irp); > + > + if (irpsp->Parameters.DeviceIoControl.OutputBufferLength < length) > + { > + irp->IoStatus.Information = 0; > + irp->IoStatus.u.Status = STATUS_BUFFER_TOO_SMALL; > + } > + else > + { > + memcpy(irp->UserBuffer, report, length); > + irp->IoStatus.Information = length; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + } > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + LeaveCriticalSection(&ext->report_cs); > +} > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > > >

1 0

Re: [PATCH] hid/tests: Add HID device enumeration test
by Sebastian Lackner Oct. 17, 2016

Oct. 17, 2016

On 14.10.2016 11:36, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > configure | 1 + > configure.ac | 1 + > dlls/hid/tests/Makefile.in | 5 +++ > dlls/hid/tests/device.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 87 insertions(+) > create mode 100644 dlls/hid/tests/Makefile.in > create mode 100644 dlls/hid/tests/device.c > > > > 0001-hid-tests-Add-HID-device-enumeration-test.txt > > > diff --git a/configure b/configure > index 99793b0..7bb6fef 100755 > --- a/configure > +++ b/configure > @@ -17936,6 +17936,7 @@ wine_fn_config_dll gpkcsp enable_gpkcsp > wine_fn_config_dll hal enable_hal > wine_fn_config_dll hhctrl.ocx enable_hhctrl_ocx clean,implib htmlhelp > wine_fn_config_dll hid enable_hid implib > +wine_fn_config_test dlls/hid/tests hid_test > wine_fn_config_dll hidclass.sys enable_hidclass_sys implib hidclass > wine_fn_config_dll hlink enable_hlink clean,implib > wine_fn_config_test dlls/hlink/tests hlink_test > diff --git a/configure.ac b/configure.ac > index ba8fd0f..9cab382 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -3025,6 +3025,7 @@ WINE_CONFIG_DLL(gpkcsp) > WINE_CONFIG_DLL(hal) > WINE_CONFIG_DLL(hhctrl.ocx,,[clean,implib],[htmlhelp]) > WINE_CONFIG_DLL(hid,,[implib]) > +WINE_CONFIG_TEST(dlls/hid/tests) > WINE_CONFIG_DLL(hidclass.sys,,[implib],[hidclass]) > WINE_CONFIG_DLL(hlink,,[clean,implib]) > WINE_CONFIG_TEST(dlls/hlink/tests) > diff --git a/dlls/hid/tests/Makefile.in b/dlls/hid/tests/Makefile.in > new file mode 100644 > index 0000000..d4a69f0 > --- /dev/null > +++ b/dlls/hid/tests/Makefile.in > @@ -0,0 +1,5 @@ > +TESTDLL = hid.dll > +IMPORTS = hid setupapi > + > +C_SRCS = \ > + device.c \ The "\" at the end seems wrong. Please note that you can also use tools/make_makefiles to update/fix this file automatically for you. > diff --git a/dlls/hid/tests/device.c b/dlls/hid/tests/device.c > new file mode 100644 > index 0000000..f3260ec > --- /dev/null > +++ b/dlls/hid/tests/device.c > @@ -0,0 +1,80 @@ > +/* > + * Copyright (c) 2016 Aric Stewart > + * > + * 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 > + */ > + > +#include "ntstatus.h" > +#define WIN32_NO_STATUS > +#include "windows.h" > +#include "setupapi.h" > + > +#ifndef WINE_NTSTATUS_DECLARED > +#define WINE_NTSTATUS_DECLARED > +typedef LONG NTSTATUS; > +#endif Such hacks should be avoided in tests. I believe you are trying to workaround a bug in the Wine hidsdi.h header file. Wine declares NTSTATUS after the includes: --- snip --- #include <hidusage.h> #include <ddk/hidpi.h> #ifndef WINE_NTSTATUS_DECLARED #define WINE_NTSTATUS_DECLARED typedef LONG NTSTATUS; #endif --- snip --- On Windows its declared before: --- snip --- typedef _Return_type_success_(return >= 0) LONG NTSTATUS; #include "hidusage.h" #include "hidpi.h" --- snip --- > + > +#include "ddk/hidsdi.h" > + > +#include "wine/test.h" > + > +static void enumerate_devices(void) > +{ > + GUID hid_guid; > + WCHAR device_name[128]; > + HDEVINFO info_set; > + DWORD index = 0; > + SP_DEVICE_INTERFACE_DATA interface_data; > + DWORD detail_size = MAX_PATH * sizeof(WCHAR); > + SP_DEVICE_INTERFACE_DETAIL_DATA_W *data; > + > + HidD_GetHidGuid(&hid_guid); > + > + ZeroMemory(&interface_data, sizeof(interface_data)); > + interface_data.cbSize = sizeof(interface_data); > + > + data = HeapAlloc(GetProcessHeap(), 0, sizeof(*data) + detail_size); > + data->cbSize = sizeof(*data); > + > + info_set = SetupDiGetClassDevsW(&hid_guid, NULL, NULL, DIGCF_DEVICEINTERFACE); Shouldn't this be released afterwards? > + while (SetupDiEnumDeviceInterfaces(info_set, NULL, &hid_guid, index, &interface_data)) > + { > + index ++; > + > + if (SetupDiGetDeviceInterfaceDetailW(info_set, &interface_data, data, detail_size, NULL, NULL)) Shouldn't the DeviceInterfaceDetailDataSize parameter also include the sizeof(*data) ? > + { > + PHIDP_PREPARSED_DATA ppd; > + HIDP_CAPS Caps; > + HANDLE file = CreateFileW(data->DevicePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); > + if (file == INVALID_HANDLE_VALUE) > + { > + trace("Failed to access device %s, likely not plugged in or access is denied.\n", wine_dbgstr_w(data->DevicePath)); > + continue; > + } > + ok(HidD_GetPreparsedData(file, &ppd), "Failed to preparsed data\n"); Is there a "get" missing in the debug string? > + ok(HidP_GetCaps(ppd, &Caps) == HIDP_STATUS_SUCCESS, "Failed to get Caps\n"); > + ok(HidD_GetProductString(file, device_name, sizeof(device_name)), "Failed to get product string\n"); > + trace("Found device %s (%s, %02x, %02x)\n", wine_dbgstr_w(device_name), wine_dbgstr_w(data->DevicePath), Caps.UsagePage, Caps.Usage); > + ok(HidD_FreePreparsedData(ppd), "Failed to free preparsed data\n"); Its a matter of taste, but usually its better to assign those values to a variable. This also allows to print the error code / GetLastError() in case of a failure. > + CloseHandle(file); > + } > + } > + HeapFree(GetProcessHeap(), 0, data); > +} > + > +START_TEST(device) > +{ > + enumerate_devices(); > +} > > >

1 0

Re: [PATCH] winebus.sys: Handle device reports for hidraw devices
by Sebastian Lackner Oct. 17, 2016

Oct. 17, 2016

On 17.10.2016 06:41, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 3 ++ > dlls/winebus.sys/bus_udev.c | 63 +++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 97 ++++++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 162 insertions(+), 1 deletion(-) > > > > 0001-winebus.sys-Handle-device-reports-for-hidraw-devices.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 7ce54bf..bcb1163 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -25,6 +25,8 @@ typedef struct > int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); > NTSTATUS (*get_string)(DEVICE_OBJECT *device, DWORD index, WCHAR *buffer, DWORD length); > + NTSTATUS (*begin_report_processing)(DEVICE_OBJECT *device, BYTE **report_buffer, DWORD *buffer_length); > + void (*end_report_processing)(DEVICE_OBJECT *device, BYTE *report_buffer); > } platform_vtbl; > > void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > @@ -37,3 +39,4 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) DECLSPEC_HIDDEN; > void bus_remove_hid_device(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > +void process_hid_report(DEVICE_OBJECT *device, const WCHAR *busidW, BYTE *report, DWORD length) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 243aabb..5307224 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -61,6 +61,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > > #ifdef HAVE_UDEV > > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > + > static struct udev *udev_context = NULL; > static DRIVER_OBJECT *udev_driver_obj = NULL; > > @@ -73,6 +75,10 @@ struct platform_private > { > struct udev_device *udev_device; > int device_fd; > + > + BYTE *report_buffer; > + int buffer_length; > + HANDLE report_thread; > }; > > static inline struct platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) > @@ -222,11 +228,68 @@ static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buf > return STATUS_SUCCESS; > } > > +static DWORD CALLBACK device_report_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + struct pollfd plfds[1]; > + > + plfds[0].fd = private->device_fd; > + plfds[0].events = POLLIN; > + > + while (1) > + { > + int size; > + if (poll(plfds, 1, -1) <= 0) continue; > + if (!private->report_buffer || private->buffer_length == 0) > + break; > + size = read(plfds[0].fd, private->report_buffer, private->buffer_length); > + if (size == -1) > + TRACE_(hid_report)("Read failed. Likely an unplugged device\n"); > + else if (size == 0) > + TRACE_(hid_report)("Failed to read report\n"); > + else > + process_hid_report(device, hidraw_busidW, private->report_buffer, size); > + } > + return 0; > +} > + > +static NTSTATUS begin_report_processing(DEVICE_OBJECT *device, BYTE **buffer, DWORD *length) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + *length = private->buffer_length = 1024; > + *buffer = private->report_buffer = HeapAlloc(GetProcessHeap(), 0, *length); > + > + private->report_thread = CreateThread(NULL, 0, device_report_thread, device, 0, NULL); > + if (!private->report_thread) > + { > + ERR("Unable to create device report thread\n"); > + return STATUS_UNSUCCESSFUL; > + } > + else > + return STATUS_SUCCESS; > +} > + > +static void end_report_processing(DEVICE_OBJECT *device, BYTE *buffer) > +{ > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + if (private->report_thread) > + { > + TerminateThread(private->report_thread, 0); TerminateThread is not really the best way to clean up this worker thread. Depending on when exactly it is called, it can corrupt internal data and crash the whole process. In this case, it would definitely be better to have some synchronization mechanism (for example event pipe) to allow a clean shutdown. > + WaitForSingleObject(private->report_thread, INFINITE); > + } > + private->buffer_length = 0; > + private->report_buffer = NULL; > + HeapFree(GetProcessHeap(), 0, buffer); > +} > + > static const platform_vtbl hidraw_vtbl = > { > compare_platform_device, > hidraw_get_reportdescriptor, > hidraw_get_string, > + begin_report_processing, > + end_report_processing, > }; > > static void try_add_device(struct udev_device *dev) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 86adbf5..f12cdf7 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -40,6 +40,7 @@ > #include "bus.h" > > WINE_DEFAULT_DEBUG_CHANNEL(plugplay); > +WINE_DECLARE_DEBUG_CHANNEL(hid_report); > > struct pnp_device > { > @@ -58,6 +59,13 @@ struct device_extension > const WCHAR *busid; /* Expected to be a static constant */ > > const platform_vtbl *vtbl; > + > + BOOL processing_started; > + BYTE *last_report; > + DWORD last_report_size; > + DWORD buffer_size; > + LIST_ENTRY irp_queue; > + > BYTE platform_private[1]; > }; > > @@ -214,6 +222,8 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->busid = busidW; > ext->vtbl = vtbl; > > + InitializeListHead(&ext->irp_queue); > + > /* add to list of pnp devices */ > pnp_dev->device = device; > list_add_tail(&pnp_devset, &pnp_dev->entry); > @@ -271,6 +281,8 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > { > struct device_extension *ext = (struct device_extension *)device->DeviceExtension; > struct pnp_device *pnp_device = ext->pnp_device; > + LIST_ENTRY *entry; > + IRP *irp; > > TRACE("(%p)\n", device); > > @@ -279,6 +291,21 @@ void bus_remove_hid_device(DEVICE_OBJECT *device) > LeaveCriticalSection(&device_list_cs); > > IoInvalidateDeviceRelations(device, RemovalRelations); > + > + /* Cancel pending IRPs */ > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + irp->IoStatus.u.Status = STATUS_CANCELLED; > + irp->IoStatus.Information = 0; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > + > + if (ext->processing_started) > + ext->vtbl->end_report_processing(device, ext->last_report); > + > HeapFree(GetProcessHeap(), 0, ext->serial); > IoDeleteDevice(device); > > @@ -432,6 +459,49 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = (strlenW((WCHAR *)irp->UserBuffer) + 1) * sizeof(WCHAR); > break; > } > + case IOCTL_HID_GET_INPUT_REPORT: > + { > + HID_XFER_PACKET *packet = (HID_XFER_PACKET*)(irp->UserBuffer); > + TRACE_(hid_report)("IOCTL_HID_GET_INPUT_REPORT\n"); > + if (!ext->processing_started) > + { > + irp->IoStatus.u.Status = status = ext->vtbl->begin_report_processing(device, &ext->last_report, &ext->buffer_size); > + if (status == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + break; > + } We might need synchronization here to ensure that only one worker thread is started (if there are multiple IOCTL_HID_GET_INPUT_REPORT requests at the same time). > + > + if (packet->reportBufferLen < ext->last_report_size) > + { > + irp->IoStatus.u.Status = status = STATUS_BUFFER_TOO_SMALL; > + break; > + } > + > + ZeroMemory(packet->reportBuffer, packet->reportBufferLen); > + memcpy(packet->reportBuffer, ext->last_report, ext->last_report_size); The worker thread always uses the same buffer. How do you ensure that the "last_report" you are copying here is a complete record, and not corrupted (for example partially old data)? > + packet->reportBufferLen = ext->last_report_size; > + irp->IoStatus.Information = ext->last_report_size; > + irp->IoStatus.u.Status = status = STATUS_SUCCESS; > + break; > + } > + case IOCTL_HID_READ_REPORT: > + { > + TRACE_(hid_report)("IOCTL_HID_READ_REPORT\n"); > + if (!ext->processing_started) > + { > + if (ext->vtbl->begin_report_processing(device, &ext->last_report, &ext->buffer_size) == STATUS_SUCCESS) > + ext->processing_started = TRUE; > + else > + { > + irp->IoStatus.u.Status = status; > + break; > + } > + } > + InsertTailList(&ext->irp_queue, &irp->Tail.Overlay.ListEntry); The irp_queue will require locking when it is accessed from multiple threads. > + status = STATUS_PENDING; Thats fine for now, but I'm planning to send some additional patches soon to fix STATUS_PENDING handling. Drivers on Windows have to call IoMarkIrpPending() when they return STATUS_PENDING. Also see: https://msdn.microsoft.com/en-us/library/windows/hardware/ff549422(v=vs.85)… """Otherwise, the I/O manager attempts to complete the IRP as soon as the dispatch routine returns control.""" and """If a driver queues incoming IRPs, it should call IoMarkIrpPending before it queues each IRP. Otherwise, an IRP could be dequeued, completed by another driver routine, and freed by the system before the call to IoMarkIrpPending occurs, thereby causing a crash. """ > + break; > + } > default: > { > ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > @@ -441,11 +511,36 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > } > } > > - IoCompleteRequest(irp, IO_NO_INCREMENT); > + if (status != STATUS_PENDING) > + IoCompleteRequest(irp, IO_NO_INCREMENT); > > return status; > } > > +void process_hid_report(DEVICE_OBJECT *device, const WCHAR *busidW, BYTE *report, DWORD length) > +{ > + struct device_extension *ext = (struct device_extension*)device->DeviceExtension; > + IRP *irp; > + LIST_ENTRY *entry; > + > + if (ext->last_report && report != ext->last_report && ext->buffer_size <= length) > + { > + memcpy(ext->last_report, report, length); > + ext->last_report_size = length; > + } > + entry = RemoveHeadList(&ext->irp_queue); > + while(entry != &ext->irp_queue) > + { > + TRACE_(hid_report)("Processing Request\n"); > + irp = CONTAINING_RECORD(entry, IRP, Tail.Overlay.ListEntry); > + memcpy(irp->UserBuffer, report, length); Shouldn't there also be some kind of length validation? > + irp->IoStatus.Information = length; > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + entry = RemoveHeadList(&ext->irp_queue); > + } > +} > + > NTSTATUS WINAPI DriverEntry( DRIVER_OBJECT *driver, UNICODE_STRING *path ) > { > static const WCHAR udevW[] = {'\\','D','r','i','v','e','r','\\','U','D','E','V',0}; > > >

1 0

Imort system certificates in crypt32@Wine
by Donat Enikeev Oct. 16, 2016

Oct. 16, 2016

[Resending in plain/text, apologies for html] Hi Guys, Watched video recently from WineConf 2015, and results around opening community looks really promising, so I am performing 3rd attempt to be useful here :) The bug https://bugs.winehq.org/show_bug.cgi?id=30187 : Cisco IP Communicator failing to setup due to 'certmgr.exe' tool fails to install certificate to the system-wide trusted certificate store. Wine uses registry-based certificates stores by default, but treats HKLM\Root store as a special case: whenever app opens such store, Crypt32 goes through hard-coded paths in rootstore.c: static const char * const CRYPT_knownLocations[] = { "/etc/ssl/certs/ca-certificates.crt", "/etc/ssl/certs", ... }; And adds all found certificates to the special store. In the context of bug, this special-case store doesn't support adding certificates, and thus Cisco IP fails to install. So a backward compatible patch (attached) that just fixes this bug looks straightforward: make a stores collection, add there HKLM\Root certificates registry store first and then, add that system store with certificates from the environment. And return the resulting collection as a store to work with. It will allow applications do whatever they used to with certificates, keeping all the linux certificates available for verification of any kind. The problem with this approach is that current wine crypt32 doesn't actually save certificates that were added to a collection of stores (the test for this attached), while Win does. Although it could be fixed with a different patch in one function, but I would like to hear your thoughts first around following questions: 1. Does this backward-compatible patch-set make sense at all and worth proceeding? Probably you have some ongoing activities 2. Do you still think that wine should import system certificates during HKLM\Root request at all, not just shipping with those from typical windows installation? 3. Have you considered different approach of utilizing system certificates in Wine? For example, import all system certificates to the *registry* during wine-prefix initialization process, and work with them from there in a way windows does (even native crypt32 will benefit from this approach). That will allow to unify and simplify crypt32 and remove all that arguable hard-coded paths in the code, and bring more familiar environment to the windows application and, at the same time, isolation. Please share your thoughts, Donnie

1 0

mscoree: Add CorIsLatestSvc function stub.
by Andrey Gusev Oct. 16, 2016

Oct. 16, 2016

>From poking at it with python ctypes, I believe this function takes 2 >pointer arguments and returns an HRESULT. >Have you found a real app that calls this? As far as I know, it's only >called by native .NET components that shouldn't be used with builtin >mscoree. At least two apps calls this function after .NET 4.5.1 (offline) have been installed.

3 2

IP dual stack
by Roman Pišl Oct. 16, 2016

Oct. 16, 2016

Hi, I sent a small patch to fix a bug where it is not possible to disable IPV6_V6ONLY as it is always enabled in WS_bind(). I have discovered, that my patch is wrong and Matthieu Nottale already proposed right solution. But it wasn't merged. What is the current status of the patch? May I help somehow? I would like to fix that bug (it breaks our application). Roman

2 1

Re: mscoree: Add CorIsLatestSvc function stub.
by Vincent Povirk Oct. 16, 2016

Oct. 16, 2016

>From poking at it with python ctypes, I believe this function takes 2 pointer arguments and returns an HRESULT. Have you found a real app that calls this? As far as I know, it's only called by native .NET components that shouldn't be used with builtin mscoree.

1 0

build WoW64 in chroots
by wylda＠volny.cz Oct. 15, 2016

Oct. 15, 2016

Hello, some year ago i built WoW64 per Wine's wiki. But that was re-phrased now or maybe today things are not so complicated in case WoW64 built in chroots32/64. Now it is not clear to me, what are the proper WoW64 steps? : 1. inside chroot64: build wine64 (add extra switch --enable-win64) ****** change chroot ****** 2. inside chroot32: build wine32_tools 3. inside chroot32: build wine32 (uses above points 1. and 2.) 4. inside chroot32: "make install" of wine32 from above point 3 to build some last bits of code (or should be wine32_tools?) ****** change chroot ****** 5. inside chroot64: "make install" of wine32 from above point 4 (but why wine32_tools dir also needs to be available in chroot64??) 6. inside chroot64: "make install" of wine64 from above point 1 (and install dir is the same like in point 5) Or can this be simplified to: 1. inside chroot64: build wine64 (add extra switch --enable-win64) ****** change chroot ****** 2. inside chroot32: build wine32_tools 3. inside chroot32: build wine32 (uses above points 1. and 2.) 4. inside chroot32: "make install" of wine32 from above point 3 to build some last bits of code ****** change chroot ****** 5. inside chroot64: "make install" of wine64 from above point 1 (and install dir is the same like in point 4) Regards, W.

1 0

Re: libwine: Add public symbol to access list of debug options.
by Sebastian Lackner Oct. 14, 2016

Oct. 14, 2016

On 09.10.2016 18:56, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41457. > > Currently, the "edit debug channels" feature of taskmgr is broken in > release builds, because: > > * "debug_options" is not exported as a public symbol > * taskmgr passes SYMOPT_PUBLICS_ONLY to SymSetOptions > > This combination does not make any sense (not even installing debug > packages is sufficient). This patch replaces debug_options with > __wine_dbg_options and makes it a public symbol. > > libs/wine/debug.c | 24 ++++++++++++------------ > libs/wine/wine.def | 1 + > libs/wine/wine.map | 1 + > programs/taskmgr/dbgchnl.c | 2 +- > programs/winedbg/info.c | 2 +- > 5 files changed, 16 insertions(+), 14 deletions(-) > Any opinions regarding this patch? An alternative approach would be to fix taskmgr (remove SYMOPT_PUBLICS_ONLY), and ask users to install debug packages if they want to use this feature. Would that be preferred? Regards, Sebastian

2 1

Re: [PATCH 1/5] wined3d: Add a quirk for GL implementations not supporting sRGB FBO attachments.
by Henri Verbeet Oct. 14, 2016

Oct. 14, 2016

On 14 October 2016 at 00:03, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > Signed-off-by: Matteo Bruni <mbruni(a)codeweavers.com> > --- > As it seems to be the case for i915 (at least with some Mesa versions). > > This is only a problem because the GL implementation also exposes > EXT_texture_sRGB_decode and when that extension is available we always > use the sRGB format. > > For bug 41052. > Just disabling EXT_texture_sRGB in this case is probably fine, but it's a little unfortunate that we already retrieve this information in init_format_fbo_compat_info(). Would it be hard to use that information instead?

1 0

Re: [PATCH v2 4/4] winehid: Implement handing internal ioctls
by Sebastian Lackner Oct. 14, 2016

Oct. 14, 2016

On 12.10.2016 18:19, Aric Stewart wrote: > > Mostly by passing them to the bus driver where platform specific actions > happen > > v2: Suggestion from Sebastian Lackner > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winehid.sys/main.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > This patch no longer applies because of the slightly modified version of patch 1/2. I have already prepared a rebased version, but I'm wondering a bit: Couldn't we just pass through ALL ioctls (without any filtering in winehid)? This would reduce the code complexity even further. HID related FIXMEs could also be printed in winebus. hid_internal_dispatch should probably use the "hid" debug channel anyway. What do you think? Regards, Sebastian

2 3

Re: [1/3] gdiplus/tests: Add tests for 0-pixel pens.
by Marvin Oct. 13, 2016

Oct. 13, 2016

Hi, While running your changed tests on Windows, 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=26156 Your paranoid android. === wxppro (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2003std (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === wvistau64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2008s64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7u (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7pro64 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w8 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w864 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w1064 (32 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === wvistau64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w2008s64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w7pro64 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w864 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0 === w1064 (64 bit graphics) === graphics.c:3982: Test failed: 1: expected 1, got 0 graphics.c:4007: Test failed: 1: expected 1, got 0

1 0

Re: [PATCH 2/2] include: Add a padding WORD to ensure that wWeight is at the correct offset.
by Marvin Oct. 13, 2016

Oct. 13, 2016

Hi, While running your changed tests on Windows, 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=26151 Your paranoid android. === wxppro (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2003std (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === wvistau64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2008s64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7u (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7pro64 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w8 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w864 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w1064 (32 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === wvistau64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w2008s64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w7pro64 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w864 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0 === w1064 (64 bit editor) === editor.c:1208: Test failed: got 700 editor.c:1217: Test failed: got 0 editor.c:1227: Test failed: got 700 editor.c:1236: Test failed: got 0

2 1

Re: [PATCH 3/4] include: Define IoSkipCurrentIrpStackLocation
by Sebastian Lackner Oct. 13, 2016

Oct. 13, 2016

On 12.10.2016 12:31, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > include/ddk/wdm.h | 2 ++ > 1 file changed, 2 insertions(+) > > > > 0003-include-Define-IoSkipCurrentIrpStackLocation.txt > > > diff --git a/include/ddk/wdm.h b/include/ddk/wdm.h > index 5602f7d..5671948 100644 > --- a/include/ddk/wdm.h > +++ b/include/ddk/wdm.h > @@ -1175,9 +1175,11 @@ NTSTATUS WINAPI ObCloseHandle(IN HANDLE handle); > # ifdef NONAMELESSSTRUCT > # define IoGetCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation) > # define IoGetNextIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation - 1) > +# define IoSkipCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.s.u2.CurrentStackLocation++); ((_Irp)->CurrentLocation++) > # else > # define IoGetCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation) > # define IoGetNextIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation - 1) > +# define IoSkipCurrentIrpStackLocation(_Irp) ((_Irp)->Tail.Overlay.u2.CurrentStackLocation++); ((_Irp)->CurrentLocation++) > # endif > #else > # ifdef NONAMELESSSTRUCT > Is this definition based on a Windows header file? I have only found two versions, either with a "{ ... }" block or with a static inline function. Your definition would not work correctly in a situation like this: if (...) IoSkipCurrentIrpStackLocation(irp); Which would be expanded to: if (...) irp->Tail.Overlay.s.u2.CurrentStackLocation++; irp->CurrentLocation++; Please note that the second statement is no longer conditional. Also, what about the two other #ifdef branches directly below? Regards, Sebastian

3 5

Re: [PATCH v4 1/2] libwine: Don't call exit in the shared library.
by Sebastian Lackner Oct. 12, 2016

Oct. 12, 2016

On 11.10.2016 16:21, Jens Reyer wrote: > From: Michael Gilbert <mgilbert(a)debian.org> > Signed-off-by: Jens Reyer <jre.winesim(a)gmail.com> > --- > libs/wine/config.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libs/wine/config.c b/libs/wine/config.c > index 3b5dd68..c0b3bdd 100644 > --- a/libs/wine/config.c > +++ b/libs/wine/config.c > @@ -68,7 +68,7 @@ static void fatal_error( const char *err, ... ) > fprintf( stderr, "wine: " ); > vfprintf( stderr, err, args ); > va_end( args ); > - exit(1); > + abort(); > } > > /* die on a fatal error */ > @@ -81,7 +81,7 @@ static void fatal_perror( const char *err, ... ) > vfprintf( stderr, err, args ); > perror( " " ); > va_end( args ); > - exit(1); > + abort(); > } > > /* malloc wrapper */ > I'm not sure if this is really a good idea. In contrast to exit, abort() might trigger the creation of a core dump. Unfortunately fatal_[p]error is also used at many places as a shortcut for "fprintf(stderr,...); exit(1)". This means after this change, a lot of users might see "Aborted (core dumped)" even for harmless error messages. Patch 2 is even more misleading, and shows such a message when the user wants to see the WINEDEBUG help: $ WINEDEBUG=help ./wine winecfg [...] Available message classes: err, warn, fixme, trace Aborted (Core dumped) Before changing things in Winelib, it would first be necessary to modify all involved tools and dlls to avoid fatal_[p]error for harmless errors. Regards, Sebastian

4 4

Compile default Visual C++ 6 project with winegcc
by A B Oct. 12, 2016

Oct. 12, 2016

I'm trying to compile the default sample win32 ,Hello World project . I did winegcc -m32 -o test2 test2.cpp . It runs ok , but resources are not loaded ,there is empty windows title and missing File and Help menus. What is the correct way to make also load the resources?

3 2

Re: [PATCH 4/4] winehid: Implement handing internal ioctls
by Sebastian Lackner Oct. 12, 2016

Oct. 12, 2016

On 12.10.2016 12:31, Aric Stewart wrote: > Mostly by passing them to the bus driver where platform specific actions > happen > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winehid.sys/main.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 48 insertions(+) > > > > 0004-winehid-Implement-handing-internal-ioctls.txt > > > diff --git a/dlls/winehid.sys/main.c b/dlls/winehid.sys/main.c > index e8c91bb..7c17321 100644 > --- a/dlls/winehid.sys/main.c > +++ b/dlls/winehid.sys/main.c > @@ -25,6 +25,7 @@ > #include "windef.h" > #include "winbase.h" > #include "winternl.h" > +#include "winioctl.h" > #include "ddk/wdm.h" > #include "ddk/hidport.h" > #include "wine/debug.h" > @@ -33,6 +34,52 @@ WINE_DEFAULT_DEBUG_CHANNEL(hid_minidriver); > > static HID_MINIDRIVER_REGISTRATION registration; > > +static NTSTATUS WINAPI internal_ioctl(DEVICE_OBJECT *device, IRP *irp) > +{ > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + Some tracing wouldn't hurt here. > + irp->IoStatus.Information = 0; > + > + switch (irpsp->Parameters.DeviceIoControl.IoControlCode) > + { > + case IOCTL_GET_PHYSICAL_DESCRIPTOR: > + TRACE("IOCTL_GET_PHYSICAL_DESCRIPTOR\n"); > + break; > + case IOCTL_HID_ACTIVATE_DEVICE: > + TRACE("IOCTL_HID_ACTIVATE_DEVICE\n"); > + break; > + case IOCTL_HID_DEACTIVATE_DEVICE: > + TRACE("IOCTL_HID_DEACTIVATE_DEVICE\n"); > + break; > + case IOCTL_HID_GET_INDEXED_STRING: > + TRACE("IOCTL_HID_GET_INDEXED_STRING\n"); > + break; I assume there are no plans (yet) to implement those. Shouldn't they be marked as FIXME then? > + case IOCTL_HID_GET_DEVICE_ATTRIBUTES: > + case IOCTL_HID_GET_DEVICE_DESCRIPTOR: > + case IOCTL_HID_GET_REPORT_DESCRIPTOR: > + case IOCTL_HID_GET_STRING: > + case IOCTL_HID_GET_INPUT_REPORT: > + case IOCTL_HID_READ_REPORT: > + case IOCTL_HID_SET_OUTPUT_REPORT: > + case IOCTL_HID_WRITE_REPORT: > + case IOCTL_HID_GET_FEATURE: > + case IOCTL_HID_SET_FEATURE: > + { > + /* All these are handled by the lower level driver */ > + IoSkipCurrentIrpStackLocation(irp); > + return IoCallDriver(((HID_DEVICE_EXTENSION*)device->DeviceExtension)->NextDeviceObject, irp); > + } > + default: > + { > + ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > + FIXME("Unsupported ioctl %x (device=%x access=%x func=%x method=%x)\n" > + , code, code >> 16, (code >> 14) & 3, (code >> 2) & 0xfff, code & 3); > + } > + } > + IoCompleteRequest( irp, IO_NO_INCREMENT ); > + return irp->IoStatus.u.Status; After IoCompleteRequest the IRP struct should not be accessed anymore. > +} > + > static NTSTATUS WINAPI add_device(DRIVER_OBJECT *driver, DEVICE_OBJECT *device) > { > TRACE("\n"); > @@ -44,6 +91,7 @@ NTSTATUS WINAPI DriverEntry(DRIVER_OBJECT *driver, UNICODE_STRING *path) > { > TRACE("%s\n", debugstr_w(path->Buffer)); > > + driver->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = internal_ioctl; > driver->DriverExtension->AddDevice = add_device; > > registration.DriverObject = driver; > > >

1 0

Re: ntdll/tests: Added a test of using NtCancelIoEx on iosb associated with pipe listening.
by Marvin Oct. 12, 2016

Oct. 12, 2016

Hi, While running your changed tests on Windows, 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=26128 Your paranoid android. === w864 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (32 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231 === w1064 (64 bit pipe) === pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 1, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 2, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 0, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 80000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: 40000000, GetLastError: 231 pipe.c:242: Test failed: CreateFile failed for sharing 3, access: c0000000, GetLastError: 231

1 0

Re: [PATCH] winebus.sys: Implement IOCTL_HID_GET_STRING for hidraw
by Sebastian Lackner Oct. 12, 2016

Oct. 12, 2016

On 12.10.2016 12:12, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus.h | 1 + > dlls/winebus.sys/bus_udev.c | 70 +++++++++++++++++++++++++++++++++++++++++++++ > dlls/winebus.sys/main.c | 11 +++++++ > 3 files changed, 82 insertions(+) > > > > 0001-winebus.sys-Implement-IOCTL_HID_GET_STRING-for-hidraw.txt > > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index 9ab242c..9094e17 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -24,6 +24,7 @@ typedef struct > { > int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > NTSTATUS (*get_reportdescriptor)(DEVICE_OBJECT *device, BYTE *buffer, DWORD length, DWORD *out_length); > + NTSTATUS (*get_string)(DEVICE_OBJECT *device, int index, WCHAR *buffer, DWORD length); > } platform_vtbl; > > void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index 22ea07d..4ded568 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -51,7 +51,9 @@ > #include "winnls.h" > #include "winternl.h" > #include "ddk/wdm.h" > +#include "ddk/hidtypes.h" > #include "wine/debug.h" > +#include "wine/unicode.h" > > #include "bus.h" > > @@ -144,10 +146,78 @@ static NTSTATUS hidraw_get_reportdescriptor(DEVICE_OBJECT *device, BYTE *buffer, > #endif > } > > +static NTSTATUS hidraw_get_string(DEVICE_OBJECT *device, int index, WCHAR *buffer, DWORD length) > +{ > + struct udev_device *usbdev; > + struct platform_private *private = impl_from_DEVICE_OBJECT(device); > + > + usbdev = udev_device_get_parent_with_subsystem_devtype(private->udev_device, "usb", "usb_device"); > + if (usbdev) > + { > + WCHAR *str = NULL; > + switch (index) > + { > + case HID_STRING_ID_IPRODUCT: > + str = get_sysattr_string(usbdev, "product"); > + break; > + case HID_STRING_ID_IMANUFACTURER: > + str = get_sysattr_string(usbdev, "manufacturer"); > + break; > + case HID_STRING_ID_ISERIALNUMBER: > + str = get_sysattr_string(usbdev, "serial"); > + break; > + default: > + ERR("Unhandled string index %i\n", index); > + return STATUS_NOT_IMPLEMENTED; > + } > + if (str) > + { > + if (strlenW(str) >= length) > + { > + HeapFree(GetProcessHeap(), 0, str); > + return STATUS_BUFFER_TOO_SMALL; > + } > + strcpyW(buffer, str); > + HeapFree(GetProcessHeap(), 0, str); > + return STATUS_SUCCESS; > + } > + else if (length) > + buffer[0] = 0; > + return STATUS_SUCCESS; Shouldn't it still return STATUS_BUFFER_TOO_SMALL when length == 0? > + } > + else > + { > +#ifdef HAVE_LINUX_HIDRAW_H > + static char str[MAX_PATH] = {0}; Isn't there a risk of race-conditions that multiple HID devices attempt to use this static buffer at the same time? > + > + switch (index) > + { > + case HID_STRING_ID_IPRODUCT: > + ioctl(private->device_fd, HIDIOCGRAWNAME(MAX_PATH), &str); > + break; > + case HID_STRING_ID_IMANUFACTURER: > + break; > + case HID_STRING_ID_ISERIALNUMBER: > + break; > + default: > + ERR("Unhandled string index %i\n", index); > + return STATUS_NOT_IMPLEMENTED; > + } > +#endif > + if (str[0]) If HAVE_LINUX_HIDRAW_H is not available this will break compilation (str undeclared). > + MultiByteToWideChar(CP_ACP, 0, str, -1, buffer, length); > + else if (length) > + buffer[0] = 0; It would be better to do length checking also in this case. > + > + return STATUS_SUCCESS; > + } > +} > + > static const platform_vtbl hidraw_vtbl = > { > compare_platform_device, > hidraw_get_reportdescriptor, > + hidraw_get_string, > }; > > static void try_add_device(struct udev_device *dev) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index ad09ec1..a7b76df 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -421,6 +421,17 @@ NTSTATUS WINAPI hid_internal_dispatch(DEVICE_OBJECT *device, IRP *irp) > irp->IoStatus.Information = length; > break; > } > + case IOCTL_HID_GET_STRING: > + { > + DWORD index = (DWORD)irpsp->Parameters.DeviceIoControl.Type3InputBuffer; This will trigger a compilation warning on 64-bit. You have to cast to a ptr-size integer type first, for example: DWORD index = (ULONG_PTR)irpsp->Parameters.DeviceIoControl.Type3InputBuffer; Also, accoding to MSDN, the content of the variable is a composite value: """Parameters.DeviceIoControl.Type3InputBuffer in the I/O stack location of the IRP contains a composite value. The two most significant bytes contain the language ID of the string to be retrieved. The two least significant bytes contain one of the following three constant values...""" > + TRACE("IOCTL_HID_GET_STRING[%i]\n", index); > + irp->IoStatus.u.Status = status = ext->vtbl->get_string(device, > + index, (WCHAR*)(irp->UserBuffer), > + irpsp->Parameters.DeviceIoControl.OutputBufferLength/sizeof(WCHAR)); > + if (status == STATUS_SUCCESS) > + irp->IoStatus.Information = (strlenW((WCHAR*)(irp->UserBuffer)) + 1) * sizeof(WCHAR); > + break; > + } > default: > { > ULONG code = irpsp->Parameters.DeviceIoControl.IoControlCode; > > >

2 2

Re: [PATCH 1/2] ws2_32: Pass completion routing to NtDeviceIoControlFile in server_ioctl_sock only if caller provided comple
by Marvin Oct. 12, 2016

Oct. 12, 2016

Hi, While running your changed tests on Windows, 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=26126 Your paranoid android. === wvistau64 (32 bit sock) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9)

1 0