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

Re: 1.8.7 maintenance release?

by Nathan Schulte

I guess it's because wine supports multiple concurrent releases. -- Nate On Mar 2, 2017 12:48, <version2013(a)openmailbox.org> wrote: > I still have much to learn. > Why have a 1.8.7 maintenance release after a 2.0 stable release? > > In advance, thank you for sharing your knowledge as to why. > > >

March 2, 2017

1.8.7 maintenance release?

by version2013＠openmailbox.org

I still have much to learn. Why have a 1.8.7 maintenance release after a 2.0 stable release? In advance, thank you for sharing your knowledge as to why.

March 2, 2017

Re: [PATCH] ws2_32: Turn SIO_GET_EXTENSION_FUNCTION_POINTER into a table

by Bruno Jesus

On Thu, Mar 2, 2017 at 2:48 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 02.03.2017 06:38, Bruno Jesus wrote: >> From: Bruno Jesus <bjesus(a)codeweavers.com> >> >> I could not find any better way to avoid compilation warning than using a typedef for the function pointer. If there is a better way I'm all ears. >> >> Signed-off-by: Bruno Jesus <bjesus(a)codeweavers.com> >> --- >> dlls/ws2_32/socket.c | 94 +++++++++++++++++++++++----------------------------- >> 1 file changed, 41 insertions(+), 53 deletions(-) > > It works fine here without any typedefs: > > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -4945,10 +4945,8 @@ INT WINAPI WSAIoctl(SOCKET s, DWORD code, LPVOID in_buff, DWORD in_size, LPVOID > > if (found) > { > - typedef void (*func_ptr)(void); > - > TRACE("-> got %s\n", guid_funcs[i].name); > - *(func_ptr *)out_buff = guid_funcs[i].func_ptr; > + *(void **)out_buff = guid_funcs[i].func_ptr; > break; > } > > What kind of compiler warning do you get? Thank you very much, I guess I tried everything but what you propose =) I'll send an updated version.

March 2, 2017

Re: [PATCH 2/2] comctl32/propsheet: Implement PSPCB_ADDREF/PSPCB_RELEASE notifications

by Dmitry Timoshkov

"Erich E. Hoover" <erich.e.hoover(a)wine-staging.com> wrote: > > I just pointed out to an ill-behaving practices you're using, and asked > > to either stop doing such bad things, or give a credit to the source. > > Since the original wine-staging patch is pretty trivial it's not a big > > problem in this case, but taking into account your practice to "borrow" > > wine-staging work it may become a real problem at some point, at least > > as a distorted image of the company you are working for. > > > > P.S. > > Thanks for confirming that the wine-staging patch was the starting point > > of your work. > > At the risk of exploding this further, it looks like Nikolay put > together a really nice patch that has undergone far more testing than > what's in staging. As we don't have a requirement on saying that a > patch is "inspired" by someone else's work I don't see any reason to > be so aggressive when this patch is clearly unique. So, I'm sorry > your feeling left out in terms of credit, but I don't think that > attacking Nikolay is a very appropriate response. While there is no any requirement to give a credit, there are things like respect to someone who did the dirty work and spent his own personal time by investigating an issue, and prepared an inital (if not even a perfect) working solution. I have to add that it took quite a bit of time and an effort to track down what exactly was wrong with Process Hacker, and why it crashes once in a while. That said, what Nikolay is doing completely kills any motivation to do any investigation work on Wine bugs. So please don't be surprised and keep moaning on every wineconf that not that much well qualified people are interested to even look on Wine bugs, not speaking about having a peek in attempting to fix something, give full credit for that to people like Nikolay who instead of doing their own hard work by investigating bugs, try to steal a low hanging fruit by "borrowing" the work done by somebody else. -- Dmitry.

March 2, 2017

Re: [PATCH] ws2_32: Turn SIO_GET_EXTENSION_FUNCTION_POINTER into a table

by Sebastian Lackner

On 02.03.2017 06:38, Bruno Jesus wrote: > From: Bruno Jesus <bjesus(a)codeweavers.com> > > I could not find any better way to avoid compilation warning than using a typedef for the function pointer. If there is a better way I'm all ears. > > Signed-off-by: Bruno Jesus <bjesus(a)codeweavers.com> > --- > dlls/ws2_32/socket.c | 94 +++++++++++++++++++++++----------------------------- > 1 file changed, 41 insertions(+), 53 deletions(-) It works fine here without any typedefs: --- a/dlls/ws2_32/socket.c +++ b/dlls/ws2_32/socket.c @@ -4945,10 +4945,8 @@ INT WINAPI WSAIoctl(SOCKET s, DWORD code, LPVOID in_buff, DWORD in_size, LPVOID if (found) { - typedef void (*func_ptr)(void); - TRACE("-> got %s\n", guid_funcs[i].name); - *(func_ptr *)out_buff = guid_funcs[i].func_ptr; + *(void **)out_buff = guid_funcs[i].func_ptr; break; } What kind of compiler warning do you get?

March 2, 2017

Re: [PATCH 2/2] comctl32/propsheet: Implement PSPCB_ADDREF/PSPCB_RELEASE notifications

by Erich E. Hoover

On Wed, Mar 1, 2017 at 10:00 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: >... > I just pointed out to an ill-behaving practices you're using, and asked > to either stop doing such bad things, or give a credit to the source. > Since the original wine-staging patch is pretty trivial it's not a big > problem in this case, but taking into account your practice to "borrow" > wine-staging work it may become a real problem at some point, at least > as a distorted image of the company you are working for. > > P.S. > Thanks for confirming that the wine-staging patch was the starting point > of your work. At the risk of exploding this further, it looks like Nikolay put together a really nice patch that has undergone far more testing than what's in staging. As we don't have a requirement on saying that a patch is "inspired" by someone else's work I don't see any reason to be so aggressive when this patch is clearly unique. So, I'm sorry your feeling left out in terms of credit, but I don't think that attacking Nikolay is a very appropriate response. Best, Erich

March 2, 2017

Re: [PATCH 1/2] mciavi32: Implement MCI_BREAK

by Andrew Eikum

On Wed, Mar 01, 2017 at 04:10:43AM -0300, Bruno Jesus wrote: > + wma->mci_break.flags = dwFlags; > + wma->mci_break.parms = *lpParms; The rest of this looks OK to me, but please guard access to wma's members with wma->cs. Andrew

March 2, 2017

Re: [v2 2/4] dinput: Handle username in EnumDevicesBySemantics.

by Andrew Eikum

Thanks for fixing these up, they look good to me. However this patch introduces a test failure: dinput.c:573: Test succeeded inside todo block: No device should be available after action mapping available=0 dinput.c:596: Test succeeded inside todo block: This user should own no devices owned=0 This is obviously fixed by your 4/4 patch, but we like to keep the tests clean in every commit. It's fine to squash the test changes into the code changes to create a 2-patch sequence with no test failures. Then I think it should be good to go in. Thanks, Andrew On Thu, Mar 02, 2017 at 12:11:24AM +0200, Jetro Jormalainen wrote: > EnumDevicesBySemantics enums only devices with given username when > DIEDBSFL_THISUSER is set and only unowned devices when > DIEDBSFL_AVAILABLEDEVICES is set. > > v2: Fixed problems noted by Andrew Eikum. > > Tested on Arch Linux and Rally Trophy Demo. > > Signed-off-by: Jetro Jormalainen <jje-wine(a)jv.jetro.fi> > --- > dlls/dinput/dinput_main.c | 111 +++++++++++++++++++++++++++++++++++++++------- > 1 file changed, 96 insertions(+), 15 deletions(-) > > diff --git a/dlls/dinput/dinput_main.c b/dlls/dinput/dinput_main.c > index 2bf9f38ba4..a59217472c 100644 > --- a/dlls/dinput/dinput_main.c > +++ b/dlls/dinput/dinput_main.c > @@ -923,6 +923,47 @@ static HRESULT WINAPI IDirectInput8WImpl_FindDevice(LPDIRECTINPUT8W iface, REFGU > return IDirectInput2WImpl_FindDevice( &This->IDirectInput7W_iface, rguid, pszName, pguidInstance ); > } > > +static BOOL should_enumerate_device(const WCHAR *username, DWORD dwFlags, > + struct list *device_players, REFGUID guid) > +{ > + BOOL should_enumerate = TRUE; > + struct DevicePlayer *device_player; > + > + /* Check if user owns this device */ > + if (dwFlags & DIEDBSFL_THISUSER && username && *username) > + { > + should_enumerate = FALSE; > + LIST_FOR_EACH_ENTRY(device_player, device_players, struct DevicePlayer, entry) > + { > + if (IsEqualGUID(&device_player->instance_guid, guid)) > + { > + if (*device_player->username && !lstrcmpW(username, device_player->username)) > + return TRUE; /* Device username matches */ > + break; > + } > + } > + } > + > + /* Check if this device is not owned by anyone */ > + if (dwFlags & DIEDBSFL_AVAILABLEDEVICES) { > + BOOL found = FALSE; > + should_enumerate = FALSE; > + LIST_FOR_EACH_ENTRY(device_player, device_players, struct DevicePlayer, entry) > + { > + if (IsEqualGUID(&device_player->instance_guid, guid)) > + { > + if (*device_player->username) > + found = TRUE; > + break; > + } > + } > + if (!found) > + return TRUE; /* Device does not have a username */ > + } > + > + return should_enumerate; > +} > + > static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > LPDIRECTINPUT8A iface, LPCSTR ptszUserName, LPDIACTIONFORMATA lpdiActionFormat, > LPDIENUMDEVICESBYSEMANTICSCBA lpCallback, > @@ -939,6 +980,7 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > int device_count = 0; > int remain; > DIDEVICEINSTANCEA *didevis = 0; > + WCHAR *username_w = 0; > > FIXME("(this=%p,%s,%p,%p,%p,%04x): semi-stub\n", This, debugstr_a(ptszUserName), lpdiActionFormat, > lpCallback, pvRef, dwFlags); > @@ -955,6 +997,14 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > > didevi.dwSize = sizeof(didevi); > > + if (ptszUserName) > + { > + int len = MultiByteToWideChar(CP_ACP, 0, ptszUserName, -1, 0, 0); > + > + username_w = HeapAlloc(GetProcessHeap(), 0, sizeof(WCHAR)*len); > + MultiByteToWideChar(CP_ACP, 0, ptszUserName, -1, username_w, len); > + } > + > /* Enumerate all the joysticks */ > for (i = 0; i < NB_DINPUT_DEVICES; i++) > { > @@ -968,7 +1018,8 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > > /* Default behavior is to enumerate attached game controllers */ > enumSuccess = dinput_devices[i]->enum_deviceA(DI8DEVCLASS_GAMECTRL, DIEDFL_ATTACHEDONLY | dwFlags, &didevi, This->dwVersion, j); > - if (enumSuccess == S_OK) > + if (enumSuccess == S_OK && > + should_enumerate_device(username_w, dwFlags, &This->device_players, &didevi.guidInstance)) > { > if (device_count++) > didevis = HeapReAlloc(GetProcessHeap(), 0, didevis, sizeof(DIDEVICEINSTANCEA)*device_count); > @@ -980,8 +1031,15 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > } > > remain = device_count; > + /* Add keyboard and mouse to remaining device count */ > if (!(dwFlags & DIEDBSFL_FORCEFEEDBACK)) > - remain += sizeof(guids)/sizeof(guids[0]); > + { > + for (i = 0; i < sizeof(guids) / sizeof(guids[0]); i++) > + { > + if (should_enumerate_device(username_w, dwFlags, &This->device_players, guids[i])) > + remain++; > + } > + } > > for (i = 0; i < device_count; i++) > { > @@ -991,26 +1049,38 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > if (lpCallback(&didevis[i], lpdid, callbackFlags, --remain, pvRef) == DIENUM_STOP) > { > HeapFree(GetProcessHeap(), 0, didevis); > + HeapFree(GetProcessHeap(), 0, username_w); > return DI_OK; > } > } > > HeapFree(GetProcessHeap(), 0, didevis); > > - if (dwFlags & DIEDBSFL_FORCEFEEDBACK) return DI_OK; > + if (dwFlags & DIEDBSFL_FORCEFEEDBACK) > + { > + HeapFree(GetProcessHeap(), 0, username_w); > + return DI_OK; > + } > > /* Enumerate keyboard and mouse */ > for(i=0; i < sizeof(guids)/sizeof(guids[0]); i++) > { > - callbackFlags = diactionformat_priorityA(lpdiActionFormat, actionMasks[i]); > + if (should_enumerate_device(username_w, dwFlags, &This->device_players, guids[i])) > + { > + callbackFlags = diactionformat_priorityA(lpdiActionFormat, actionMasks[i]); > > - IDirectInput_CreateDevice(iface, guids[i], &lpdid, NULL); > - IDirectInputDevice_GetDeviceInfo(lpdid, &didevi); > + IDirectInput_CreateDevice(iface, guids[i], &lpdid, NULL); > + IDirectInputDevice_GetDeviceInfo(lpdid, &didevi); > > - if (lpCallback(&didevi, lpdid, callbackFlags, sizeof(guids)/sizeof(guids[0]) - (i+1), pvRef) == DIENUM_STOP) > - return DI_OK; > + if (lpCallback(&didevi, lpdid, callbackFlags, --remain, pvRef) == DIENUM_STOP) > + { > + HeapFree(GetProcessHeap(), 0, username_w); > + return DI_OK; > + } > + } > } > > + HeapFree(GetProcessHeap(), 0, username_w); > return DI_OK; > } > > @@ -1049,7 +1119,8 @@ static HRESULT WINAPI IDirectInput8WImpl_EnumDevicesBySemantics( > > /* Default behavior is to enumerate attached game controllers */ > enumSuccess = dinput_devices[i]->enum_deviceW(DI8DEVCLASS_GAMECTRL, DIEDFL_ATTACHEDONLY | dwFlags, &didevi, This->dwVersion, j); > - if (enumSuccess == S_OK) > + if (enumSuccess == S_OK && > + should_enumerate_device(ptszUserName, dwFlags, &This->device_players, &didevi.guidInstance)) > { > if (device_count++) > didevis = HeapReAlloc(GetProcessHeap(), 0, didevis, sizeof(DIDEVICEINSTANCEW)*device_count); > @@ -1061,8 +1132,15 @@ static HRESULT WINAPI IDirectInput8WImpl_EnumDevicesBySemantics( > } > > remain = device_count; > + /* Add keyboard and mouse to remaining device count */ > if (!(dwFlags & DIEDBSFL_FORCEFEEDBACK)) > - remain += sizeof(guids)/sizeof(guids[0]); > + { > + for (i = 0; i < sizeof(guids) / sizeof(guids[0]); i++) > + { > + if (should_enumerate_device(ptszUserName, dwFlags, &This->device_players, guids[i])) > + remain++; > + } > + } > > for (i = 0; i < device_count; i++) > { > @@ -1083,13 +1161,16 @@ static HRESULT WINAPI IDirectInput8WImpl_EnumDevicesBySemantics( > /* Enumerate keyboard and mouse */ > for(i=0; i < sizeof(guids)/sizeof(guids[0]); i++) > { > - callbackFlags = diactionformat_priorityW(lpdiActionFormat, actionMasks[i]); > + if (should_enumerate_device(ptszUserName, dwFlags, &This->device_players, guids[i])) > + { > + callbackFlags = diactionformat_priorityW(lpdiActionFormat, actionMasks[i]); > > - IDirectInput_CreateDevice(iface, guids[i], &lpdid, NULL); > - IDirectInputDevice_GetDeviceInfo(lpdid, &didevi); > + IDirectInput_CreateDevice(iface, guids[i], &lpdid, NULL); > + IDirectInputDevice_GetDeviceInfo(lpdid, &didevi); > > - if (lpCallback(&didevi, lpdid, callbackFlags, sizeof(guids)/sizeof(guids[0]) - (i+1), pvRef) == DIENUM_STOP) > - return DI_OK; > + if (lpCallback(&didevi, lpdid, callbackFlags, --remain, pvRef) == DIENUM_STOP) > + return DI_OK; > + } > } > > return DI_OK; > -- > 2.11.0 > > >

March 2, 2017

Re: [PATCH 1/5] winebus.sys: Handle linux input event device via udev

by Roderick Colenbrander

On Mon, Feb 27, 2017 at 8:52 AM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > On 27.02.2017 17:22, Aric Stewart wrote: >> On 2/27/17 10:00 AM, Sebastian Lackner wrote: >>> I assume this is meant as a fallback, if we don't have access to >>> hidraw, right? If you plan to use this as a replacement for dinput, >>> it would be better to implement it without fixed dependency on >>> udev. >>> >> Likely users using HID for gamepads and joysticks will end up this >> route by default because all the permissions are automatically setup >> for us. Also then user will get to leverage all the work done in the >> kernel to handle devices that do not behave well on the HID side or >> which do not show up at all using hidraw (Xbox Controllers for >> example) >> >> The dependency for udev is for common device discovery. I feel like I >> still want that dependency unless we write our own device plug and >> unplug discovery system. > > Are you sure that there are no systems out there where we have linux > events, but no udev? If yes the current solution is fine, but otherwise > we should at least implement a fallback method similar to how its done > in dinput (basically, just trying to open all devices in the range 0 .. > MAX_JOYDEV). > >>> Does it hurt when both hidraw and input event devices are found? If >>> yes, it would be better to filter duplicates somewhere else, >>> instead of using registry keys. >>> >> You can get duplicate devices, on being talking to the hidraw device >> and one to the linux event device, but both are the same physical >> device. I have explored a little bit to try to find if there is a >> good way to detect if a device is duplicated but it has not proven to >> be immediately easy. > > If it can cause problems it is probably still worth the effort. There > might also be systems where hidraw devices have access permissions by > default, and we don't want to get duplicated input events then. > >> Also then the question because which device is >> preferred if we find a duplicate. >> > > I think preferring hidraw might be slightly better. Some devices also > offer their own control utilities, and those would probably not work when > using linux input events. Nevertheless, its a matter of taste and we can > certainly discuss about that. For some devices hidraw is a decent option, but in general my strong recommendation is to stay the hell away from hidraw. The HID spec itself has many holes (e.g. no good button mapping) and many vendors implement device specific methods to do certain things (e.g. for controller rumble, sensors, ..). The Linux kernel has a generic HID parser, but there are so many fixups for devices, quirks and custom handling. It is best to have the Linux kernel's evdev framework do the work. However the downside of evdev is that there is no 1:1 mapping between HID devices and evdev devices. More and more devices are reported as composite devices through evdev including Wacom devices, Wii controllers, Sony controllers and more. It means for each HID device there are multiple evdev nodes with the same product/vendor/version, but different capabilities. Some separate out touch functionality, others do it for sensors. Ideally this patch series would 'merge' devices, maybe based on EVIOCGPHYS or something (or serial number). > > Best regards, > Sebastian > >

March 2, 2017

Re: [PATCH v2 3/5] winebus.sys: Process device reports for linux event devices

by Roderick Colenbrander

Hi Aric, Some quick feedback on this patch as well. High-level looks okay (need to have a deeper dive), one thing really implement proper support for EV_SYN and particular you MUST handle SYN_DROPPEPD, it has bitten me many times. Basically if you don't process input fast enough (can happen for various reason either you are too slow or device is too fast), evdev drops input and you can't trust the state. When input is dropped SYN_DROPPED is sent and you must follow the required procedures to recover (ignore any input data until next SYN_REPORT). I'm not sure how you are marking the end of input reports, but you may want to mark a report completed based on the proper SYN flag as well else you may build up unneeded input latency. Didn't follow too closely what you are doing yet. Thanks, Roderick On Mon, Feb 27, 2017 at 9:33 AM, Aric Stewart <aric(a)codeweavers.com> wrote: > > v2: Updates from Sebastian Lackner > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 203 ++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 197 insertions(+), 6 deletions(-) > > > > >

March 2, 2017