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

Re: [PATCH] msvcrt: Implement __std_type_info_hash

by Piotr Caban

Hi Alexandre, On 10/04/16 22:49, GOUJON Alexandre wrote: > - MSVCRT_size_t hash = 0x811c9dc5; > + MSVCRT_size_t hash; > + MSVCRT_size_t fnvPrime; > const char *p; > > + if(sizeof(void*) == sizeof(int)) > + { > + hash = 0x811c9dc5; > + fnvPrime = 0x1000193; > + } > + else > + { > + hash = 0xcbf29ce484222325; > + fnvPrime = 0x100000001b3; > + } > + Please change name of fnvPrime variable to something like fnv_prime. Also you will need to initialize it using #ifdef, something like this should work: #ifdef _WIN64 MSVCRT_size_t hash = ... #else MSVCRT_size_t hash = ... #endif > + return hash ^ (hash >> 32); This will also cause compilation warning during 32-bit compilation. > diff --git a/dlls/ucrtbase/tests/cpp.c b/dlls/ucrtbase/tests/cpp.c > index 1a01fea..659269c 100644 > --- a/dlls/ucrtbase/tests/cpp.c > +++ b/dlls/ucrtbase/tests/cpp.c > @@ -163,7 +163,7 @@ static void test___std_type_info(void) > ti1.mangled[2] = 0; > hash1 = p___std_type_info_hash(&ti1); > #ifdef _WIN64 > - todo_wine ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); > + ok(hash1 == 0xcbf29ce44fd0bfc1, "hash = %p\n", (void*)hash1); And this. Thanks, Piotr

Oct. 5, 2016

Re: [PATCH 4/7] wined3d: Avoid using destroyed context.

by Józef Kucia

On Tue, Oct 4, 2016 at 10:43 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 3 October 2016 at 17:27, Józef Kucia <joseph.kucia(a)gmail.com> wrote: >> I think this fix is correct. The device keeps a reference to the implicit >> swapchain. The implicit swapchain is destroyed just before leaving from >> wined3d_device_uninit_3d() so it should be safe to call context_acquire(). >> >> This problem occurs only for additional swapchains and that's why it happens >> only in test_swapchain_flip(). > > You're probably right. (Although that's not to say the code wouldn't > benefit from being a little more robust. I think it's hard to reason > about.) Is state_unbind_shaders() required? I assume it's because > unbinding the shaders needs to happen before destroying the shader > backend, but would delaying the context_acquire() call until after the > wine_rb_clear() call also work? Yes, delaying context_acquire() would also work.

Oct. 5, 2016

wine-1.8.5-rc2 Available

by Michael Stefaniuc

Hello guys, wine-1.8.5-rc2 is now available, including the tag: https://github.com/mstefani/wine-stable https://static-winehq.rhcloud.com/stable/ The commit "user32: Prevent resetting WS_MINIMIZE through SetWindowLong." was deferred as Józef and Alexandre were not convinced about that one. bye michael

Oct. 5, 2016

Re: [PATCH] winebus.sys: Implement common IRP_MJ_POWER handling

by Sebastian Lackner

On 05.10.2016 02:23, Aric Stewart wrote: > +NTSTATUS WINAPI common_power_dispatch(DEVICE_OBJECT *device, IRP *irp) > +{ > + IO_STACK_LOCATION *irpsp = IoGetCurrentIrpStackLocation(irp); > + TRACE("Device entering power state %i\n", irpsp->Parameters.Power.State.DeviceState); You are ignoring the MinorFunction parameter here. DeviceState is only valid for IRP_MN_SET_POWER, but there are also other IRP_MJ_POWER requests. For those it would be better to keep irp->IoStatus.u.Status set the original value, similar to how its done in common_pnp_dispatch. I would also suggest to add a TRACE with device and irp here (and to common_pnp_dispatch), otherwise it is difficult to interpret the meaning of the logged values. The TRACE in handle_IRP_MN_QUERY_ID could be removed then. Regards, Sebastian > + irp->IoStatus.u.Status = STATUS_SUCCESS; > + IoCompleteRequest(irp, IO_NO_INCREMENT); > + return STATUS_SUCCESS; > +} > +

Oct. 4, 2016

Re: [PATCH] msinfo32: Display an About dialog when the program is run.

by Alex Henrie

Thanks for the feedback! -Alex

Oct. 4, 2016

Re: [PATCH] msinfo32: Display an About dialog when the program is run.

by Alex Henrie

2016-10-04 3:06 GMT-06:00 Hugh McMaster <hugh.mcmaster(a)outlook.com>: > On Monday, 3 October 2016 5:14 PM, Alex Henrie wrote: > >> msinfo32 does not take any command line arguments, so I changed >> WINE_FIXME to WINE_TRACE. > > No. msinfo32 accepts many command line arguments. See, for example, https://support.microsoft.com/en-au/kb/300887. Thanks, I should have googled it. I ran `msinfo32 /?` and when nothing appeared on the console, I assumed that the program had no command line mode. I see now that the /? switch actually opened a help window. >> +#include <shlwapi.h> >> + >> +#include "resource.h" >> +#include "shellapi.h" >> #include "wine/debug.h" > > resource.h should come after wine/debug.h. You might also like to put shellapi.h before shlwapi.h. Okay, will do. >> int wmain(int argc, WCHAR *argv[]) >> { >> + static const WCHAR wineSystemInfoW[] = >> + {'W','i','n','e',' ','S','y','s','t','e','m',' ','I','n','f','o','r','m','a','t','i','o','n',0}; >> + WCHAR systemInfo[64]; >> int i; >> >> - WINE_FIXME("stub:"); >> for (i = 0; i < argc; i++) >> - WINE_FIXME(" %s", wine_dbgstr_w(argv[i])); >> - WINE_FIXME("\n"); >> + WINE_TRACE(" %s", wine_dbgstr_w(argv[i])); >> + WINE_TRACE("\n"); >> + >> + LoadStringW(GetModuleHandleW(NULL), STRING_SYSTEM_INFO, systemInfo, sizeof(systemInfo)/sizeof(WCHAR)); >> + ShellAboutW(NULL, systemInfo, wineSystemInfoW, NULL); > > The dialog box text should also be translatable. Add it to the string table as well. I modeled this after Notepad, where "Wine Notepad" is not translatable. After looking at more examples, I think I'd prefer to make the third parameter NULL. >> +#include "resource.h" >> + >> +STRINGTABLE >> +{ >> + STRING_SYSTEM_INFO, "System Information" >> +} > >> +#define STRING_SYSTEM_INFO 0x170 > > Why #define this as 0x170? We normally start string tables from, e.g., 100, 101, 1000 or 1001. Also modeled after Notepad, where this string happens to be 0x170. I'll change it to 100. -Alex

Oct. 4, 2016

Re: [PATCH] msinfo32: Display an About dialog when the program is run.

by Hugh McMaster

On Monday, 3 October 2016 5:14 PM, Alex Henrie wrote: > msinfo32 does not take any command line arguments, so I changed > WINE_FIXME to WINE_TRACE. No. msinfo32 accepts many command line arguments. See, for example, https://support.microsoft.com/en-au/kb/300887. > +#include <shlwapi.h> > + > +#include "resource.h" > +#include "shellapi.h" > #include "wine/debug.h" resource.h should come after wine/debug.h. You might also like to put shellapi.h before shlwapi.h. > int wmain(int argc, WCHAR *argv[]) > { > + static const WCHAR wineSystemInfoW[] = > + {'W','i','n','e',' ','S','y','s','t','e','m',' ','I','n','f','o','r','m','a','t','i','o','n',0}; > + WCHAR systemInfo[64]; > int i; > > - WINE_FIXME("stub:"); > for (i = 0; i < argc; i++) > - WINE_FIXME(" %s", wine_dbgstr_w(argv[i])); > - WINE_FIXME("\n"); > + WINE_TRACE(" %s", wine_dbgstr_w(argv[i])); > + WINE_TRACE("\n"); > + > + LoadStringW(GetModuleHandleW(NULL), STRING_SYSTEM_INFO, systemInfo, sizeof(systemInfo)/sizeof(WCHAR)); > + ShellAboutW(NULL, systemInfo, wineSystemInfoW, NULL); The dialog box text should also be translatable. Add it to the string table as well. > +#include "resource.h" > + > +STRINGTABLE > +{ > + STRING_SYSTEM_INFO, "System Information" > +} > +#define STRING_SYSTEM_INFO 0x170 Why #define this as 0x170? We normally start string tables from, e.g., 100, 101, 1000 or 1001.

Oct. 4, 2016

Re: [PATCH 4/7] wined3d: Avoid using destroyed context.

by Henri Verbeet

On 3 October 2016 at 17:27, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > 03.10.2016 3:47 PM "Henri Verbeet" <hverbeet(a)gmail.com>: >> I think it may be harder to fix than this. If state_unbind_resources() >> can end up destroying the (primary) swapchain, it's not safe to call >> context_acquire() afterwards. Which means it's unsafe to unload >> resources or even unload a different SRV. The reason destroying the >> RTVs is currently safe, is that we unloaded resources earlier, so >> releasing the references to the resources for those views shouldn't >> acquire a context to destroy e.g. the GL texture again, but that's >> already more fragile than I'd like. Perhaps we should just delay >> destroying the context until leaving the last level. > > I think this fix is correct. The device keeps a reference to the implicit > swapchain. The implicit swapchain is destroyed just before leaving from > wined3d_device_uninit_3d() so it should be safe to call context_acquire(). > > This problem occurs only for additional swapchains and that's why it happens > only in test_swapchain_flip(). You're probably right. (Although that's not to say the code wouldn't benefit from being a little more robust. I think it's hard to reason about.) Is state_unbind_shaders() required? I assume it's because unbinding the shaders needs to happen before destroying the shader backend, but would delaying the context_acquire() call until after the wine_rb_clear() call also work?

Oct. 4, 2016

Re: [3/3] winebus.sys: Add implementation for device removal. (v9)

by Aric Stewart

On 10/3/16 2:05 PM, Sebastian Lackner wrote: > On 03.10.2016 17:27, Aric Stewart wrote: >> >> On 10/3/16 6:29 AM, Sebastian Lackner wrote: >>>> From: Aric Stewart <aric(a)codeweavers.com> >>>> >>>> Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >>>> Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> >>>> --- >>>> >>>> Second part of 126774. Besides splitting, I've also done the following changes: >>>> >>>> * Rename find_hid_device -> bus_find_hid_device, for consistency with other bus_*_hid_*() functions. >>>> * Do not append timestamp to the device names. To make the code more robust, I've modified >>>> bus_remove_hid_device() to defer the release of the pnp_device pointer. If there are more >>>> problems I would prefer to fix them properly, adding the timestamp seems more like a hack to me. >>>> * Some style improvements. >>>> >>>> @Aric: I'm not sure if you are aware of it, but there is currently still a bug somewhere which >>>> causes a crash during RemovalRelations when trying to remove a driver which was never added properly. >>>> I feel like the right place to fix that is somewhere in ntoskrnl. Are you aware of this issue? >>>> >> Yes, that bug is fixed by patch 126650, which has not been reviewed or committed yet. > > The patch does not help here. It also sounds like you are trying to fix a different > problem because the issue I have can be reproduced without winehid/hidclass. > Nevertheless, one way to improve 126650 would be to remove the unnecessary "break;" > after the return. > Ahh yes, Got ahead of myself. I will try to get a chance to circle up on that and fix 126650, As for this crash I am betting it has to do with not handling the power ioctls in the base device. I will try to dig into that also when I get a chance. Traveling for the next 3 weeks so my time may be intermittent but I will try to carve out a chance to get to this. -aric > Regards, > Sebastian >

Oct. 3, 2016

Re: [PATCH 3/7] wined3d: Bind dummy textures to all texture image units.

by Józef Kucia

On Mon, Oct 3, 2016 at 3:46 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 3 October 2016 at 00:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: >> Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> >> --- >> dlls/wined3d/context.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> > Not that there's anything wrong with this, but what's the idea behind it? > > It should be useful when we remove hardcoded sampler limits for D3D10+.

Oct. 3, 2016

Beating the Wineconf drum

by Jeremy White

Hey folks, A reminder, it's now just 6 weeks until Wineconf. We still have funding available, so write to me privately if you'd like to come, but don't have the funds. We could also use topics for conversation; you can email the wineconf mailing list, or edit the wiki page directly; either way is fine. Cheers, Jeremy p.s. And this is going to be my point of pain: https://www.winehq.org/~jwhite/latest.html

Oct. 3, 2016

Re: [3/3] winebus.sys: Add implementation for device removal. (v9)

by Sebastian Lackner

On 03.10.2016 17:27, Aric Stewart wrote: > > On 10/3/16 6:29 AM, Sebastian Lackner wrote: >> > From: Aric Stewart <aric(a)codeweavers.com> >> > >> > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> >> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> >> > --- >> > >> > Second part of 126774. Besides splitting, I've also done the following changes: >> > >> > * Rename find_hid_device -> bus_find_hid_device, for consistency with other bus_*_hid_*() functions. >> > * Do not append timestamp to the device names. To make the code more robust, I've modified >> > bus_remove_hid_device() to defer the release of the pnp_device pointer. If there are more >> > problems I would prefer to fix them properly, adding the timestamp seems more like a hack to me. >> > * Some style improvements. >> > >> > @Aric: I'm not sure if you are aware of it, but there is currently still a bug somewhere which >> > causes a crash during RemovalRelations when trying to remove a driver which was never added properly. >> > I feel like the right place to fix that is somewhere in ntoskrnl. Are you aware of this issue? >> > > Yes, that bug is fixed by patch 126650, which has not been reviewed or committed yet. The patch does not help here. It also sounds like you are trying to fix a different problem because the issue I have can be reproduced without winehid/hidclass. Nevertheless, one way to improve 126650 would be to remove the unnecessary "break;" after the return. Regards, Sebastian

Oct. 3, 2016

RE: [PATCH] make_unicode: Change handling of Turkish i to match Windows

by Daniel Lehman

>Are you sure about that? If I understood the original patch description correctly, Wine currently has the following mappings: > İ -> i > i -> I > > I -> i > ı -> I > >While the correct (Windows) mappings would be: > > with LCMAP_LINGUISTIC_CASING and tr or az locale: > İ <-> i > I <-> ı > > without LCMAP_LINGUISTIC_CASING: > I <-> i > İ -> İ > ı -> ı right >I think doing this properly would need to take the data from https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unicode.org_Public_…>v0AaA02WDVZTGQo77gZQ&m=ojKq6NWxBIZ_S4HX7WhgcDIxqKLoSwppiNx8q7fScrw&s=j6sJ7DQkj8fKnFLo3i4DPMNpiKklnG9qGITUzV9Nq4M&e= into account. https://urldefense.proofpoint.com/v2/url?u=http->3A__www.unicode.org_reports_tr44_-23Casemapping&d=DQIFaQ&c=n6-cguzQvX_tUIrZOS_4Og&r=0->v0AaA02WDVZTGQo77gZQ&m=ojKq6NWxBIZ_S4HX7WhgcDIxqKLoSwppiNx8q7fScrw&s=HlbjMHfc_H_7HQHRfjtzip3RyjOaoF0WSCQPmQNP8Zc&e= seems relevant. I'll take a look Thanks daniel

Oct. 3, 2016

Re: [3/3] winebus.sys: Add implementation for device removal. (v9)

by Aric Stewart

On 10/3/16 6:29 AM, Sebastian Lackner wrote: > From: Aric Stewart <aric(a)codeweavers.com> > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > Second part of 126774. Besides splitting, I've also done the following changes: > > * Rename find_hid_device -> bus_find_hid_device, for consistency with other bus_*_hid_*() functions. > * Do not append timestamp to the device names. To make the code more robust, I've modified > bus_remove_hid_device() to defer the release of the pnp_device pointer. If there are more > problems I would prefer to fix them properly, adding the timestamp seems more like a hack to me. > * Some style improvements. > > @Aric: I'm not sure if you are aware of it, but there is currently still a bug somewhere which > causes a crash during RemovalRelations when trying to remove a driver which was never added properly. > I feel like the right place to fix that is somewhere in ntoskrnl. Are you aware of this issue? > Yes, that bug is fixed by patch 126650, which has not been reviewed or committed yet. -aric > dlls/winebus.sys/bus.h | 16 +++++++-- > dlls/winebus.sys/bus_udev.c | 38 ++++++++++++++++++++-- > dlls/winebus.sys/main.c | 74 ++++++++++++++++++++++++++++++++++++++------ > 3 files changed, 111 insertions(+), 17 deletions(-) > > diff --git a/dlls/winebus.sys/bus.h b/dlls/winebus.sys/bus.h > index dcb50f2..099558b 100644 > --- a/dlls/winebus.sys/bus.h > +++ b/dlls/winebus.sys/bus.h > @@ -19,8 +19,18 @@ > /* Busses */ > NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry_path) DECLSPEC_HIDDEN; > > +/* Native device function table */ > +typedef struct > +{ > + int (*compare_platform_device)(DEVICE_OBJECT *device, void *platform_dev); > +} platform_vtbl; > + > +void *get_platform_private(DEVICE_OBJECT *device) DECLSPEC_HIDDEN; > + > /* HID Plug and Play Bus */ > NTSTATUS WINAPI common_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp) DECLSPEC_HIDDEN; > -DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, > - WORD pid, DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > - const GUID *class) DECLSPEC_HIDDEN; > +DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, WORD vid, WORD pid, > + DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > + const GUID *class, const platform_vtbl *vtbl, DWORD platform_data_size) DECLSPEC_HIDDEN; > +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; > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index b1d6c3f..d798c53 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -61,6 +61,16 @@ static const WCHAR hidraw_busidW[] = {'H','I','D','R','A','W',0}; > #include "initguid.h" > DEFINE_GUID(GUID_DEVCLASS_HIDRAW, 0x3def44ad,0x242e,0x46e5,0x82,0x6d,0x70,0x72,0x13,0xf3,0xaa,0x81); > > +struct platform_private > +{ > + struct udev_device *udev_device; > +}; > + > +static inline struct platform_private *impl_from_DEVICE_OBJECT(DEVICE_OBJECT *device) > +{ > + return (struct platform_private *)get_platform_private(device); > +} > + > static DWORD get_sysattr_dword(struct udev_device *dev, const char *sysattr, int base) > { > const char *attr = udev_device_get_sysattr_value(dev, sysattr); > @@ -88,6 +98,18 @@ static WCHAR *get_sysattr_string(struct udev_device *dev, const char *sysattr) > return dst; > } > > +static int compare_platform_device(DEVICE_OBJECT *device, void *platform_dev) > +{ > + struct udev_device *dev1 = impl_from_DEVICE_OBJECT(device)->udev_device; > + struct udev_device *dev2 = platform_dev; > + return strcmp(udev_device_get_syspath(dev1), udev_device_get_syspath(dev2)); > +} > + > +static const platform_vtbl hidraw_vtbl = > +{ > + compare_platform_device, > +}; > + > static void try_add_device(struct udev_device *dev) > { > DWORD vid = 0, pid = 0, version = 0; > @@ -123,12 +145,15 @@ static void try_add_device(struct udev_device *dev) > subsystem = udev_device_get_subsystem(dev); > if (strcmp(subsystem, "hidraw") == 0) > { > - device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, dev, vid, pid, > - version, 0, serial, FALSE, &GUID_DEVCLASS_HIDRAW); > + device = bus_create_hid_device(udev_driver_obj, hidraw_busidW, vid, pid, version, 0, serial, FALSE, > + &GUID_DEVCLASS_HIDRAW, &hidraw_vtbl, sizeof(struct platform_private)); > } > > if (device) > - udev_device_ref(dev); > + { > + impl_from_DEVICE_OBJECT(device)->udev_device = udev_device_ref(dev); > + IoInvalidateDeviceRelations(device, BusRelations); > + } > else > WARN("Ignoring device %s with subsystem %s\n", debugstr_a(devnode), subsystem); > > @@ -137,7 +162,12 @@ static void try_add_device(struct udev_device *dev) > > static void try_remove_device(struct udev_device *dev) > { > - /* FIXME */ > + DEVICE_OBJECT *device = bus_find_hid_device(&hidraw_vtbl, dev); > + if (!device) return; > + > + dev = impl_from_DEVICE_OBJECT(device)->udev_device; > + bus_remove_hid_device(device); > + udev_device_unref(dev); > } > > static void build_initial_deviceset(void) > diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c > index 1364eab..09a59d6 100644 > --- a/dlls/winebus.sys/main.c > +++ b/dlls/winebus.sys/main.c > @@ -47,13 +47,16 @@ struct pnp_device > > struct device_extension > { > - void *native; /* Must be the first member of the structure */ > + struct pnp_device *pnp_device; > > WORD vid, pid; > DWORD uid, version, index; > BOOL is_gamepad; > WCHAR *serial; > const WCHAR *busid; /* Expected to be a static constant */ > + > + const platform_vtbl *vtbl; > + BYTE platform_private[1]; > }; > > static CRITICAL_SECTION device_list_cs; > @@ -80,6 +83,12 @@ static inline WCHAR *strdupW(const WCHAR *src) > return dst; > } > > +void *get_platform_private(DEVICE_OBJECT *device) > +{ > + struct device_extension *ext = (struct device_extension *)device->DeviceExtension; > + return ext->platform_private; > +} > + > static DWORD get_vidpid_index(WORD vid, WORD pid) > { > struct pnp_device *ptr; > @@ -157,9 +166,9 @@ static WCHAR *get_compatible_ids(DEVICE_OBJECT *device) > return dst; > } > > -DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, void *native, WORD vid, > - WORD pid, DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > - const GUID *class) > +DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, WORD vid, WORD pid, > + DWORD version, DWORD uid, const WCHAR *serialW, BOOL is_gamepad, > + const GUID *class, const platform_vtbl *vtbl, DWORD platform_data_size) > { > static const WCHAR device_name_fmtW[] = {'\\','D','e','v','i','c','e','\\','%','s','#','%','p',0}; > struct device_extension *ext; > @@ -169,16 +178,18 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > WCHAR dev_name[256]; > HDEVINFO devinfo; > NTSTATUS status; > + DWORD length; > > - TRACE("(%p, %s, %p, %04x, %04x, %u, %u, %s, %u, %s)\n", driver, debugstr_w(busidW), native, > - vid, pid, version, uid, debugstr_w(serialW), is_gamepad, debugstr_guid(class)); > + TRACE("(%p, %s, %04x, %04x, %u, %u, %s, %u, %s, %p, %u)\n", driver, debugstr_w(busidW), vid, pid, > + version, uid, debugstr_w(serialW), is_gamepad, debugstr_guid(class), vtbl, platform_data_size); > > if (!(pnp_dev = HeapAlloc(GetProcessHeap(), 0, sizeof(*pnp_dev)))) > return NULL; > > - sprintfW(dev_name, device_name_fmtW, busidW, native); > + sprintfW(dev_name, device_name_fmtW, busidW, pnp_dev); > RtlInitUnicodeString(&nameW, dev_name); > - status = IoCreateDevice(driver, sizeof(*ext), &nameW, 0, 0, FALSE, &device); > + length = FIELD_OFFSET(struct device_extension, platform_private[platform_data_size]); > + status = IoCreateDevice(driver, length, &nameW, 0, 0, FALSE, &device); > if (status) > { > FIXME("failed to create device error %x\n", status); > @@ -190,7 +201,7 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > > /* fill out device_extension struct */ > ext = (struct device_extension *)device->DeviceExtension; > - ext->native = native; > + ext->pnp_device = pnp_dev; > ext->vid = vid; > ext->pid = pid; > ext->uid = uid; > @@ -199,6 +210,7 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > ext->is_gamepad = is_gamepad; > ext->serial = strdupW(serialW); > ext->busid = busidW; > + ext->vtbl = vtbl; > > /* add to list of pnp devices */ > pnp_dev->device = device; > @@ -226,10 +238,52 @@ DEVICE_OBJECT *bus_create_hid_device(DRIVER_OBJECT *driver, const WCHAR *busidW, > else > ERR("failed to get ClassDevs: %x\n", GetLastError()); > > - IoInvalidateDeviceRelations(device, BusRelations); > return device; > } > > +DEVICE_OBJECT *bus_find_hid_device(const platform_vtbl *vtbl, void *platform_dev) > +{ > + struct pnp_device *dev; > + DEVICE_OBJECT *ret = NULL; > + > + TRACE("(%p, %p)\n", vtbl, platform_dev); > + > + EnterCriticalSection(&device_list_cs); > + LIST_FOR_EACH_ENTRY(dev, &pnp_devset, struct pnp_device, entry) > + { > + struct device_extension *ext = (struct device_extension *)dev->device->DeviceExtension; > + if (ext->vtbl != vtbl) continue; > + if (ext->vtbl->compare_platform_device(dev->device, platform_dev) == 0) > + { > + ret = dev->device; > + break; > + } > + } > + LeaveCriticalSection(&device_list_cs); > + > + TRACE("returning %p\n", ret); > + return ret; > +} > + > +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; > + > + TRACE("(%p)\n", device); > + > + EnterCriticalSection(&device_list_cs); > + list_remove(&pnp_device->entry); > + LeaveCriticalSection(&device_list_cs); > + > + IoInvalidateDeviceRelations(device, RemovalRelations); > + HeapFree(GetProcessHeap(), 0, ext->serial); > + IoDeleteDevice(device); > + > + /* pnp_device must be released after the device is gone */ > + HeapFree(GetProcessHeap(), 0, pnp_device); > +} > + > static NTSTATUS handle_IRP_MN_QUERY_ID(DEVICE_OBJECT *device, IRP *irp) > { > NTSTATUS status = irp->IoStatus.u.Status; >

Oct. 3, 2016

Re: [PATCH 4/7] wined3d: Avoid using destroyed context.

by Józef Kucia

03.10.2016 3:47 PM "Henri Verbeet" <hverbeet(a)gmail.com>: > I think it may be harder to fix than this. If state_unbind_resources() > can end up destroying the (primary) swapchain, it's not safe to call > context_acquire() afterwards. Which means it's unsafe to unload > resources or even unload a different SRV. The reason destroying the > RTVs is currently safe, is that we unloaded resources earlier, so > releasing the references to the resources for those views shouldn't > acquire a context to destroy e.g. the GL texture again, but that's > already more fragile than I'd like. Perhaps we should just delay > destroying the context until leaving the last level. I think this fix is correct. The device keeps a reference to the implicit swapchain. The implicit swapchain is destroyed just before leaving from wined3d_device_uninit_3d() so it should be safe to call context_acquire(). This problem occurs only for additional swapchains and that's why it happens only in test_swapchain_flip().

Oct. 3, 2016

Re: [PATCH v2] d2d1: Initial implementation of HWND render target

by Nikolay Sivov

On 03.10.2016 16:45, Henri Verbeet wrote: > On 1 October 2016 at 18:12, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: >> +void d2d_d3d_render_target_set_pixel_size(ID2D1RenderTarget *iface, UINT32 width, UINT32 height) >> +{ >> + struct d2d_d3d_render_target *render_target = impl_from_ID2D1RenderTarget(iface); >> + render_target->pixel_size.width = width; >> + render_target->pixel_size.height = height; >> +} >> + > I think d2d_d3d_render_target_create_rtv() already does this. > > Right, most likely a leftover from earlier version.

Oct. 3, 2016

Re: [PATCH 4/7] wined3d: Avoid using destroyed context.

by Henri Verbeet

On 3 October 2016 at 00:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > The swapchain can be destroyed by state_unbind_resources() > if the only reference to a swapchain is kept by a shader resource view. > This happens in d3d10core and d3d11 tests when a device is destroyed > in test_swapchain_flip(). > I think it may be harder to fix than this. If state_unbind_resources() can end up destroying the (primary) swapchain, it's not safe to call context_acquire() afterwards. Which means it's unsafe to unload resources or even unload a different SRV. The reason destroying the RTVs is currently safe, is that we unloaded resources earlier, so releasing the references to the resources for those views shouldn't acquire a context to destroy e.g. the GL texture again, but that's already more fragile than I'd like. Perhaps we should just delay destroying the context until leaving the last level.

Oct. 3, 2016

Re: [PATCH 3/7] wined3d: Bind dummy textures to all texture image units.

by Henri Verbeet

On 3 October 2016 at 00:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/wined3d/context.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Not that there's anything wrong with this, but what's the idea behind it?

Oct. 3, 2016

Re: [PATCH 1/7] wined3d: Use MAX_TEXTURES instead of magic number.

by Henri Verbeet

On 3 October 2016 at 00:38, Józef Kucia <jkucia(a)codeweavers.com> wrote: > diff --git a/dlls/wined3d/ati_fragment_shader.c b/dlls/wined3d/ati_fragment_shader.c > index cd32009..7a04f76 100644 > --- a/dlls/wined3d/ati_fragment_shader.c > +++ b/dlls/wined3d/ati_fragment_shader.c > @@ -1307,7 +1307,7 @@ static void atifs_get_caps(const struct wined3d_gl_info *gl_info, struct fragmen > * The proper fix for this is not to use GL_ATI_fragment_shader on cards newer than the > * r200 series and use an ARB or GLSL shader instead > */ > - caps->MaxTextureBlendStages = 8; > + caps->MaxTextureBlendStages = MAX_TEXTURES; For what it's worth, note that ati_fragment_shader.c in particular has a couple of other places with hard 8's as well.

Oct. 3, 2016

Re: [PATCH] d3d11: Add stub implementation for deferred context.

by Henri Verbeet

Other than some minor comments below, the patch itself is mostly ok. Unfortunately, the issue is that it's not clear that this is the right direction for implementing deferred contexts. In particular, it seems likely that we'll handle the difference between immediate and deferred contexts inside wined3d, and only have a single implementation in d3d11. Of course that's one of those things where you won't know how well it works until you try it. On 2 October 2016 at 08:39, Kimmo Myllyvirta <kimmo.myllyvirta(a)gmail.com> wrote: > -»······view.c > +»······view.c \ > +»······deferred.c It's pretty minor, but please keep these ordered. > + if (context) > + { Is it valid for context to be NULL here? The test doesn't cover it. > + *context = (ID3D11DeviceContext *)&object->ID3D11DeviceContext_iface; That cast seems unnecessary.

Oct. 3, 2016

Re: [PATCH v2] d2d1: Initial implementation of HWND render target

by Henri Verbeet

On 1 October 2016 at 18:12, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +void d2d_d3d_render_target_set_pixel_size(ID2D1RenderTarget *iface, UINT32 width, UINT32 height) > +{ > + struct d2d_d3d_render_target *render_target = impl_from_ID2D1RenderTarget(iface); > + render_target->pixel_size.width = width; > + render_target->pixel_size.height = height; > +} > + I think d2d_d3d_render_target_create_rtv() already does this.

Oct. 3, 2016

Re: [2/2] [v2] kernel32: Implement LCMAP_HALFWIDTH.

by Marvin

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=25991 Your paranoid android. === w1064 (32 bit locale) === locale.c:2648: Test failed: LCMapStringEx should fail with bad locale name locale.c:2649: Test failed: unexpected error code -559038737 locale.c:2740: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4476: Test failed: IsValidLocaleName should have failed locale.c:4478: Test failed: IsValidLocaleName should have failed locale.c:4861: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4863: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2648: Test failed: LCMapStringEx should fail with bad locale name locale.c:2649: Test failed: unexpected error code -559038737 locale.c:2740: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4476: Test failed: IsValidLocaleName should have failed locale.c:4478: Test failed: IsValidLocaleName should have failed locale.c:4861: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4863: Test failed: For id 7, Expected IVC, got ''

Oct. 2, 2016

Re: [1/2] [v2] kernel32: Implement LCMAP_FULLWIDTH.

by Marvin

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=25990 Your paranoid android. === w1064 (32 bit locale) === locale.c:2644: Test failed: LCMapStringEx should fail with bad locale name locale.c:2645: Test failed: unexpected error code -559038737 locale.c:2736: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4472: Test failed: IsValidLocaleName should have failed locale.c:4474: Test failed: IsValidLocaleName should have failed locale.c:4857: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4859: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2644: Test failed: LCMapStringEx should fail with bad locale name locale.c:2645: Test failed: unexpected error code -559038737 locale.c:2736: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4472: Test failed: IsValidLocaleName should have failed locale.c:4474: Test failed: IsValidLocaleName should have failed locale.c:4857: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4859: Test failed: For id 7, Expected IVC, got ''

Oct. 2, 2016

Re: [PATCH 6/6] ddraw/tests: Add D3DVIEWPORT2 transform tests.

by Marvin

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=25984 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Oct. 1, 2016

Re: [PATCH 4/6] ddraw: Apply legacy clipspace to d3d2.

by Marvin

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=25983 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Oct. 1, 2016

Re: [PATCH 3/6] ddraw/tests: Test d3d2 and 3 drawing with non-standard viewports (v2).

by Marvin

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=25982 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2391: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2546: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Oct. 1, 2016

Re: [PATCH 2/6] ddraw: Store d3d1 projection matrices in device->legacy_projection.

by Marvin

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=25981 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Oct. 1, 2016

Re: [PATCH 1/6] ddraw/tests: Add position tests for D3DPROCESSVERTICES_TRANSFORM (v2).

by Marvin

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=25980 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2240: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

Oct. 1, 2016

Re: [PATCH] d2d1: Initial implementation of HWND render target

by Marvin

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=25973 Your paranoid android. === wvistau64 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w2008s64 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w7u (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w7pro64 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w8 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w864 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === w1064 (32 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 0040D955 === wvistau64 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174 === w2008s64 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174 === w7pro64 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174 === w864 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174 === w1064 (64 bit d2d1) === d2d1.c:2874: Test failed: Failed to create factory, hr 0x80070057. d2d1: unhandled exception c0000005 at 000000000040D174

Oct. 1, 2016

Re: [2/2] user32: Also release GMEM_FIXED data in free_cached_data.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > I assume the purpose of the check was to detect GMEM_MOVEABLE handles, in order to mimic > WinXP/Win2003 behavior for SetClipboardData. Unfortunately, the cache implemented in > GetClipboardData() also uses GMEM_FIXED, which means even sane apps will leak memory > on each cache flush. > > Tests suggest that Windows Vista+ also release GMEM_FIXED pointers passed to > SetClipboardData, so there is probably no need to keep this hack. That's probably OK, but could you please add the test case too? -- Alexandre Julliard julliard(a)winehq.org

Oct. 1, 2016

Re: [PATCH] make_unicode: Change handling of Turkish i to match Windows

by Henri Verbeet

On 30 September 2016 at 18:32, Daniel Lehman <dlehman(a)esri.com> wrote: > Wine's LCMapString currently calls tolowerW and doesn't support the LCMAP_LINGUISTIC_CASING flag. But the current table contains the conversions the LCMAP_LINGUISTIC_CASING flag needs if added in the future > Are you sure about that? If I understood the original patch description correctly, Wine currently has the following mappings: İ -> i i -> I I -> i ı -> I While the correct (Windows) mappings would be: with LCMAP_LINGUISTIC_CASING and tr or az locale: İ <-> i I <-> ı without LCMAP_LINGUISTIC_CASING: I <-> i İ -> İ ı -> ı I think doing this properly would need to take the data from http://www.unicode.org/Public/9.0.0/ucd/SpecialCasing.txt into account. http://www.unicode.org/reports/tr44/#Casemapping seems relevant.

Oct. 1, 2016

Re: Some code ambiguity in tab control code.

by John Found

So, the continuation of my story, how I fixed the tooltips for tab control and what problems and differences with Windows I found. (It does not seems to be the bestseller of the year, but still can help someone) At the end I was able to fix the missing tooltips by the following code: .ti TOOLINFO invoke SendMessageW, [hEditorsHost], TCM_GETTOOLTIPS, 0, 0 mov esi, eax mov [.ti.cbSize], sizeof.TOOLINFO mov [.ti.uFlags], TTF_SUBCLASS or TTF_IDISHWND ; it does not work with the tab ctrl ID mov eax, [hTabControl] mov [.ti.uId], eax mov eax, [.hParent] ; it handles the TTN_NEEDTEXTW mov [.ti.hwnd], eax mov [.ti.lpszText], LPSTR_TEXTCALLBACK lea eax, [.ti] invoke SendMessageW, esi, TTM_ADDTOOLW, 0, eax Now I got TTN_NEEDTEXTW notifications and everything seemed to work ok, but when testing on Windows it didn't work at all. After some investigation, I found out that the content of the NMHDR structure passed is different in WINE and Windows. The differences are in the .idFrom field: WINE puts there the handle of the tab control window (maybe because of the above TTF_IFISHWND). Windows always puts there the index of the tab hovered. (NB: Actually, the WINE approach of passing the handle of the tab control in .idFrom field is much better and natural, because it gives an easy way to identify which control have to provide the tooltip text) In attempt to make the same behavior in WINE and Windows, I tried to remove the TTF_IDISHWND flag from the above code and to put in [.ti.uId] the unique ID of the tab control, but then the tooltips stopped to appear in WINE at all. As a result, in order to have the same behavior in Windows and WINE, one should never use .idFrom field, but instead, identify the hovered tab, by using TCM_HITTEST: lea ebx, [.pnt] invoke GetCursorPos, ebx mov ecx, [.pnt.x] mov edx, [.pnt.y] mov [.tchi.pt.x], ecx mov [.tchi.pt.y], edx lea ebx, [.tchi] invoke ScreenToClient, esi, ebx invoke SendMessageW, esi, TCM_HITTEST, 0, ebx On Fri, 30 Sep 2016 00:49:14 +0300 John Found <johnfound(a)asm32.info> wrote: > Hi. > > Trying without success to show tooltips for a tabcontrol, I found the following problems in the source code. Notice, that my skills in C++ are poor, so it is very possible the following is a false alarm. > > I am quote https://github.com/wine-mirror/wine/blob/master/dlls/comctl32/tab.c (hope it is the proper source code) > > This seems to be a bug: WM_LBUTTONDOWN is relayed in the WM_MOUSEMOVE handler. But WM_LBUTTONDOWN will always hide the tooltip. WM_MOUSEMOVE instead will set the timer for showing the tooltip. > > > static LRESULT > > TAB_MouseMove (TAB_INFO *infoPtr, WPARAM wParam, LPARAM lParam) > > { > > int redrawLeave; > > int redrawEnter; > > > > if (infoPtr->hwndToolTip) > > TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, > > WM_LBUTTONDOWN, wParam, lParam); > > > > /* Determine which tab to highlight. Redraw tabs which change highlight > > ** status. */ > > TAB_RecalcHotTrack(infoPtr, &lParam, &redrawLeave, &redrawEnter); > > > > hottrack_refresh (infoPtr, redrawLeave); > > hottrack_refresh (infoPtr, redrawEnter); > > > > return 0; > > } > > > The WM_LBUTTONDOWN is relayed twice? Why? It is not exactly a bug, but sub-optimal. > > > static LRESULT > > TAB_LButtonDown (TAB_INFO *infoPtr, WPARAM wParam, LPARAM lParam) > > { > > POINT pt; > > INT newItem; > > UINT dummy; > > > > if (infoPtr->hwndToolTip) > > TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, > > WM_LBUTTONDOWN, wParam, lParam); > > > > if (!(infoPtr->dwStyle & TCS_FOCUSNEVER)) { > > SetFocus (infoPtr->hwnd); > > } > > > > if (infoPtr->hwndToolTip) > > TAB_RelayEvent (infoPtr->hwndToolTip, infoPtr->hwnd, > > WM_LBUTTONDOWN, wParam, lParam); > > -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

Oct. 1, 2016

Re: [PATCH v6] winebus.sys: Watch for hid raw device addition and removal

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: >> @@ -178,6 +273,13 @@ NTSTATUS WINAPI udev_driver_init(DRIVER_OBJECT *driver, UNICODE_STRING *registry >> driver->MajorFunction[IRP_MJ_PNP] = common_pnp_dispatch; >> >> build_initial_deviceset(); >> + >> + if (!CreateThread(NULL, 0, deviceloop_thread, NULL, 0, NULL)) >> + { >> + ERR("Unable to create udev device thread\n"); >> + return STATUS_UNSUCCESSFUL; > > Wouldn't it make sense to proceed anyway? The initial device set could still > be working properly (and, you are not cleaning up already added drivers here). Actually, you probably want to load the initial device set from the thread, since it has to be done after setting up the monitoring. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2016