March 2014 - Wine-devel - list.winehq.org

Re: [PATCH] msxml3: Respect stylesheet output mode when dumping resulting document
by Marvin 13 Mar '14

13 Mar '14

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://newtestbot.winehq.org/JobDetails.pl?Key=5654 Your paranoid android. === w8 (32 bit domdoc) === domdoc.c:10385: Test failed: got 00000000 domdoc.c:10399: Test failed: got 00000000 domdoc.c:10451: Test failed: got 0 domdoc.c:10476: Test failed: got 00000000 domdoc.c:10550: Test failed: got 00000000 domdoc.c:10565: Test failed: got 00000000 domdoc.c:10619: Test failed: got 0 domdoc.c:11268: Test failed: got 00000000 domdoc.c:11294: Test failed: got 00000000

1 0

Re: [PATCH 2/3] mshtml: Added IHTMLDocument7 stub implementation.
by Alexandre Julliard 13 Mar '14

13 Mar '14

Jacek Caban <jacek(a)codeweavers.com> writes: > Due to how tests are written, we need to switch to IWebBrowserPriv2IE9 > in the same patch. > > --- > dlls/ieframe/ieframe.h | 2 +- > dlls/ieframe/navigate.c | 104 +---- > dlls/mshtml/Makefile.in | 1 + > dlls/mshtml/htmldoc.c | 4 + > dlls/mshtml/htmldoc7.c | 939 +++++++++++++++++++++++++++++++++++++++++++ Merging htmldoc3 and htmldoc5 was a good start, couldn't we do this with the rest of the htmldoc implementations too? There are way too many files in that dll already. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: schedsvc: Add Task Scheduler service. Try 2.
by Dmitry Timoshkov 13 Mar '14

13 Mar '14

Hi, Is there a reason why this patch is marked as 'pending'? -- Dmitry.

2 16

Glorious winetestbot results, why this matters
by Jeremy White 13 Mar '14

13 Mar '14

So here's today's data: http://www.winehq.org/~jwhite/31faed571d5a.html The main changes are the addition of some new failures in mshtml; failures that Marvin actually pointed out here: http://www.winehq.org/pipermail/wine-devel/2014-March/103419.html The glorious result is that if I get to publicly shame anyone, it's both Jacek and Alexandre. For someone with my JR, that's a rare opportunity <grin>. But really, it illustrates the problem: Alexandre does not trust the new test bot results, so he did not wait for testbot review of patches, and so he did not catch a problem. We need to restore that trust. That's why this matters. Cheers, Jeremy p.s. Looks like Francois's patch has fixed winmm:mci (yay!), and a few tests that my script felt were 'solved' have proven themselves to be actually intermittent (comctl:propsheet and user32:listbox)

5 5

[RFC 5/11] Linux FF: Linux effect parameters: time parameters
by Elias Vanderstuyft 12 Mar '14

12 Mar '14

a) Because of the higher time resolution of DInput parameters (in microseconds instead of milliseconds), e.g. dwPeriod, and because truncating may result in "periodic.period == 0", while "1 <= dwPeriod (non-zero) < 1000", and because "periodic.period == 0" is an invalid argument, we might set periodic.period to the smallest non-zero value (that is 1) when dwPeriod is non-zero, to avoid unnecessary exceptions. So change in dinput/effect_linuxinput.c:488 : This->effect.u.periodic.period = tsp->dwPeriod / 1000; to : if (0 < tsp->dwPeriod && tsp->dwPeriod <= 1000) This->effect.u.periodic.period = 1; else This->effect.u.periodic.period = tsp->dwPeriod / 1000; b) Anticipate if dwPeriod < 0, otherwise periodic.period will incorrectly wrap around because it's unsigned. We can choose to let periodic.period be proportional to: - 0 (driver will generate EINVAL) - abs(dwPeriod) (no error, and is mathematically more correct) Choosing the latter, so change in dinput/effect_linuxinput.c:488 : if (0 < tsp->dwPeriod && tsp->dwPeriod <= 1000) This->effect.u.periodic.period = 1; else This->effect.u.periodic.period = tsp->dwPeriod / 1000; to : if (tsp->dwPeriod && abs(tsp->dwPeriod) <= 1000) This->effect.u.periodic.period = 1; else This->effect.u.periodic.period = abs(tsp->dwPeriod) / 1000; c) Something similar is needed for 'dwDuration': Set infinite replay-length in linux by "replay.length == 0": discussion: http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08459.html Knowing that DInput "INFINITE == -1", we convert -1 to 0. If "peff->dwDuration == 0", we can: - not start the effect - set the effect duration to the absolute minimum I would choose the latter, because otherwise more behaviour of the code would change. And lastly, we don't throw exceptions when "dwDuration < 0": MSDN does not require us to throw DIERR_INVALIDPARAM. So, change in dinput/effect_linuxinput.c:191 : if (dwFlags & DIEP_DURATION) { peff->dwDuration = (DWORD)This->effect.replay.length * 1000; } to : if (dwFlags & DIEP_DURATION) { peff->dwDuration = (This->effect.replay.length ? (DWORD)This->effect.replay.length * 1000 : -1); } And change in dinput/effect_linuxinput.c:424 : if (dwFlags & DIEP_DURATION) This->effect.replay.length = peff->dwDuration / 1000; to : if (dwFlags & DIEP_DURATION) { if (peff->dwDuration == -1) This->effect.replay.length = 0; // Infinity else if (peff->dwDuration > 1000) This->effect.replay.length = peff->dwDuration / 1000; else This->effect.replay.length = 1; // Smallest non-zero value } Elias

2 4

[RFC 2/11] Linux FF: Linux effect status management
by Elias Vanderstuyft 12 Mar '14

12 Mar '14

a) This is a bug that is either the responsibility of the Linux kernel, or of Wine: It is caused by the following situation: When uploading an effect, the specific kernel device driver may return an error, e.g. EINVAL for example when a periodic's effect period is set to zero. This error will then be returned by "ioctl(*(This->fd), EVIOCSFF, &This->effect)". With or without error, one can find out that /drivers/input/ff-core.c:input_ff_upload(...) is called, which will set effect->id >= 0, if it was set to -1 (=> new effect created) by the user. But in case of an error: - Assume effect->id was set to -1 by the user: The error is reported by ff->upload(...) at /drivers/input/ff-core.c:167, the effect->id will also be set >= 0 (*). The offending effect will not be saved in the ff->effects[] array (***). - Assume effect->id was set >= 0 by the user (and ff->effects[effect->id] is a valid existing effect): The error is reported by ff->upload(...) at /drivers/input/ff-core.c:167, the effect->id will remain unchanged (**). The offending effect will not overwrite the ff->effects[effect->id] element (****). Is this (see *, **, *** and ****) desired behavior? - If yes: Change the following in Wine's dinput/effect_linuxinput.c:84 : LinuxInputEffectImpl *This = impl_from_IDirectInputEffect(iface); TRACE("(this=%p)\n", This); if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { to : LinuxInputEffectImpl *This = impl_from_IDirectInputEffect(iface); int effectId_old; TRACE("(this=%p)\n", This); effectId_old = This->effect.id; if (ioctl(*(This->fd), EVIOCSFF, &This->effect) == -1) { This->effect.id = effectId_old; - If no for *: Kernel code /drivers/input/ff-core.c:input_ff_upload(...) has to be patched to revert "effect->id" back to its original value set by the user, which is only needed when the initial (by user) value of "effect->id" was equal to -1. - If no for **** (or maybe also ***): ff->effects[effect->id] could be replaced by an 'empty' effect (however this can get complex because the effect's type has to remain unchanged) This would be a change in the kernel code /drivers/input/ff-core.c:input_ff_upload(...). - If no for **: I don't really know. Discussion is needed. - In my opinion, **, *** and **** are desired behavior, while * should leave the effect->id at -1. In that case, Wine's dinput implementation does not have to be patched, and the kernel code only should apply a minor patch. => This has been discussed (see http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08513.html) and the following is true: My opinion appeared to be correct, but for to be sure, I was recommended to apply the change in Wine as well. b) Be more precise in returning errors. In dinput/effect_linuxinput.c:89, change : if (errno == ENOMEM) { return DIERR_DEVICEFULL; } else { FIXME("Could not upload effect. Assuming a disconnected device %d \"%s\".\n", *This->fd, strerror(errno)); return DIERR_INPUTLOST; } to : switch (errno) { case EINVAL: TRACE("Could not upload effect: Invalid argument.\n"); return DIERR_INVALIDPARAM; case ENOSPC: TRACE("Could not upload effect: No space left on device.\n"); return DIERR_DEVICEFULL; case ENOMEM: TRACE("Could not upload effect: Out of memory.\n"); return DIERR_OUTOFMEMORY; default: FIXME("Could not upload effect. Assuming a disconnected device %d \"%s\".\n", *This->fd, strerror(errno)); return DIERR_INPUTLOST; } c) The following in dinput/effect_linuxinput.c:336 : if (res != DI_OK) should be probably : if (FAILED(res)) for example if a device reports S_FALSE because it has already updated an identical effect. The same for line 549: if (retval != DI_OK) should be then : if (FAILED(retval)) Elias

2 4

Re: [5/6] user32: Set capture on the owner of popup menus.
by Alexandre Julliard 12 Mar '14

12 Mar '14

Vincent Povirk <madewokherd(a)gmail.com> writes: > @@ -2057,6 +2057,19 @@ BOOL CDECL X11DRV_ScrollDC( HDC hdc, INT dx, INT dy, HRGN update ) > } > > > +BOOL CALLBACK find_popup_menu_window(HWND hwnd, LPARAM lparam) > +{ > + HWND *result = (HWND*)lparam; > + > + if (GetClassLongW(hwnd, GCW_ATOM) == MAKEINTATOM(32768)) > + { > + *result = hwnd; > + return FALSE; > + } That's ugly and unreliable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] d3d8/tests: Test GetPrivateData size behavior.
by Marvin 12 Mar '14

12 Mar '14

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://newtestbot.winehq.org/JobDetails.pl?Key=5629 Your paranoid android. === w8 (32 bit device) === device.c:2396: Test failed: Expected foreground window 000901BC, got 00010048.

1 0

Re: [PATCH 4/5] d3d8/tests: Use a custom GUID for the private data tests.
by Marvin 12 Mar '14

12 Mar '14

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://newtestbot.winehq.org/JobDetails.pl?Key=5628 Your paranoid android. === w8 (32 bit device) === device.c:2396: Test failed: Expected foreground window 000401E4, got 00010048. device.c:3038: Test failed: Expected wndproc 0x40fa10, got 0x40fa10.

1 0

Valve has released a Direct3D to OpenGL translator (for a subset of Direct3D 9.0c)
by Artem S. Tashkinov 12 Mar '14

12 Mar '14

Hi, Just wanted to let everyone know that Valve has released a Direct3D to OpenGL translator (for a subset of Direct3D 9.0c). More here: https://github.com/ValveSoftware/ToGL I don't know if it's of any use for Wine development however. The license is as permissive as possible - in short Valve allows to do anything with their code. Artem

2 1