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

[RFC 0/11] Linux FF: Intro

by Elias Vanderstuyft

Hi, This is the sequel of the mail with title: "Discussion and Improvement of Wine's Linux Force Feedback implementation". This mail is meant to give an introduction to the next 11 mails: All tests were performed using wine-1.7.11-206-g82b3813 (but none of the files of which I propose changes to be made in, are affected in the current (2014-03-04) wine-version 1.7.13) Because I haven't created any (formal) patch yet (and instead first request for comments), I tried to keep the line numbers to reference the affected files more or less based to the version I started from, where I could. However, the orig code of a (informal) patch that has to be applied after (and thus is dependent of) a previous patch, may be different from the initial code of the wine-version I started from. After having discussed everything, I will send a proper patchset. In these mails, sometimes 'FEdit' is mentioned: it's a MS application that allows to create all FF effect types (except CustomForce and rumble/vibration effects), and therefore the ideal test application. Physical behavior is compared between Windows7 (using Logitech MOMO wheel with latest drivers installed) running in Virtualbox, and my patched Wine-version. In the end, (using a dummy FF driver on the Linux side, thanks to Michal Malý), the behavior of Wine is almost (limitations caused by the dummy ff driver, such as updating an effect while playing is not implemented) identical, if not better (in some aspects) then the Windows equivalent. Sometimes I refer to linux-input mailing lists to prove a statement, because the links may vanish (unlikely though), I provide the titles corresponding with the links: (http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08513.html) "ff-core effect id handling in case of a failed effect upload" (http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08459.html) "Questions about the documentation/specification of Linux ForceFeedback input.h" Subjects [11] ------------- - Joystick control panel program [2] - Linux effect status management [3] - Linux effect parameter: start delay [1] - Linux effect parameter: periodic effect's phase [1] - Linux effect parameters: time parameters [3] - Linux effect: conditional effect's parameters [2] - Linux effect: axes [1] - Linux effect direction [7] - Linux effect parameters (global) [6] - Linux joystick initialization [1] - Debug message fixes/additions [6] Elias

March 4, 2014

Re: advapi32/tests: Change the current directory to a place that will be writable.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > --- > dlls/advapi32/tests/eventlog.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/dlls/advapi32/tests/eventlog.c b/dlls/advapi32/tests/eventlog.c > index f71529c..525d606 100644 > --- a/dlls/advapi32/tests/eventlog.c > +++ b/dlls/advapi32/tests/eventlog.c > @@ -1123,6 +1123,8 @@ static void cleanup_eventlog(void) > > START_TEST(eventlog) > { > + char curdir[MAX_PATH], tmpdir[MAX_PATH]; > + > SetLastError(0xdeadbeef); > CloseEventLog(NULL); > if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > @@ -1131,6 +1133,10 @@ START_TEST(eventlog) > return; > } > > + GetCurrentDirectoryA(MAX_PATH, curdir); > + GetTempPathA(MAX_PATH, tmpdir); > + SetCurrentDirectoryA(tmpdir); > + A better fix would be to build proper temp file names with GetTempPath+GetTempFileName instead of using hardcoded paths in file creation calls. -- Alexandre Julliard julliard(a)winehq.org

March 4, 2014

Re: Need help getting Win32_PNPEntity WMI class added

by Luke A. Guest

On Mon, 2014-03-03 at 20:07 +0100, Hans Leidekker wrote: > > > > My understanding of that code was that it always returned 1 object no > > matter what the client was asking for as the api can always return less > > than what was asked for. If this is not right, then the wine code needs > > to return as many objects as possible, right? > > Right, and if the client really expects WBEM_S_NO_ERROR then we'd need at least > 20 instances of Win32_PNPEntity. No, you should still be able to return less if that is available. You should not have to have at least 20 or whatever to get it to work. Also, does the timeout not handled FIXME really go into a busy loop or am I reading that macro wrong? Luke.

March 4, 2014

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Qian Hong

On Thu, Oct 10, 2013 at 6:48 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Qian Hong <qhong(a)codeweavers.com> writes: > >> --- >> dlls/user32/tests/winstation.c | 57 >> ++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 57 insertions(+) > > Can you please fix the test failures introduced by your previous changes > first? cf. https://test.winehq.org/data/tests/user32:winstation.html There is still some failing everyday, could I try a patch which increasing the sleeping timeout? That's the most possible fix I'm thinking about. Other wise it is likely I'll have to be show on Jeremy's wall of shame some day... -- Regards, Qian Hong - http://www.codeweavers.com

March 4, 2014

Re: mshtml: Don't use fragment navigation for SuperNavigate calls.

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://newtestbot.winehq.org/JobDetails.pl?Key=5364 Your paranoid android. === w8 (32 bit webbrowser) === webbrowser.c:425: Test failed: unexpected nsCmdID 74 webbrowser.c:702: Test failed: V_I4(V_VARIANTREF(flags)) = 100, expected 0x40 or 0 webbrowser.c:442: Test failed: unexpected nCmdID 119 webbrowser.c:454: Test failed: unexpected nCmdID 178 webbrowser.c:454: Test failed: unexpected nCmdID 135 webbrowser.c:425: Test failed: unexpected nsCmdID 74

March 4, 2014

Re: Discussion and Improvement of Wine's Linux Force Feedback implementation

by Andrew Eikum

On Tue, Mar 04, 2014 at 09:59:20AM +0100, Elias Vanderstuyft wrote: > I'll send them with the prefix "[RFC x/11] Linux FF: <subject>". > Am I allowed to send this? > Yeah, absolutely. I've already gone through around 40% of your document and written some comments. They'll be much easier to discuss if the subjects are split up. I'll send them as replies when you get the smaller mails off to wine-devel. Andrew

March 4, 2014

Drowning in a sea of red

by Jeremy White

Alright, one month from FOSDEM, and I load test.winehq.org, and I'm still drowning in a sea of red. This is shameful. At the very least, all of the test bot vms should be green. How do we fix this? Should I just pick one failure at a time, and publicly shake it, and shame people as best I can? Cheers, Jeremy

March 4, 2014

Discussion and Improvement of Wine's Linux Force Feedback implementation

by Elias Vanderstuyft

Hi, In the past few weeks I've been reviewing Wine's Linux Force Feedback implementation. I annotated questions and proposals for improvement and bundled them in a file "Improvements.txt". Now, I think it's time to post my results, before someone begins to work on the dinput files I started from (untouched since wine-1.7.11-206-g82b3813). The reason why I don't send this to wine-patches, is because it is more a review and discussion, than a set of actual diff-generated patch files. Because of the rather massive amount of text I've written, I decided to split them up in separate mails in subjects, each containing 3 questions/proposals on average: Subjects [11] ------------- - Joystick control panel program [2] - Linux effect status management [3] - Linux effect parameter: start delay [1] - Linux effect parameter: periodic effect's phase [1] - Linux effect parameters: time parameters [3] - Linux effect: conditional effect's parameters [2] - Linux effect: axes [1] - Linux effect direction [7] - Linux effect parameters (global) [6] - Linux joystick initialization [1] - Debug message fixes/additions [6] I'll send them with the prefix "[RFC x/11] Linux FF: <subject>". Am I allowed to send this? Thanks, Elias

March 4, 2014

Re: [PATCH 5/5] winex11: Add support for WGL_WINE_make_current extension. (resend)

by Ken Thomases

On Mar 3, 2014, at 10:50 AM, Alexandre Julliard wrote: > Ken Thomases <ken(a)codeweavers.com> writes: > >> --- >> dlls/winex11.drv/opengl.c | 37 +++++++++++++++++++++++++++++++++++++ >> 1 files changed, 37 insertions(+), 0 deletions(-) > > It doesn't work here: > > ../../../tools/runtest -q -P wine -T ../../.. -M d3d8.dll -p d3d8_test.exe.so device && touch device.ok > X Error of failed request: GLXBadDrawable > Major opcode of failed request: 153 (GLX) > Minor opcode of failed request: 26 (X_GLXMakeContextCurrent) > Serial number of failed request: 3303 > Current serial number in output stream: 3303 > make: *** [device.ok] Error 1 Oops. Crud. I remember *intending* to test under X11 before submitting, but clearly didn't. Sorry. The issue behind this error raises questions as to whether this extension is worthwhile. It was designed for the case where the DC had been released. What's happened here is the window has been destroyed. I can detect that case in a somewhat hacky manner and then make wglMakeContextCurrentWINE() fail. But the existing functions would have failed in that case, already. So, while the extension lets us restore the context in some additional cases, it's not clear that it helps in enough to be worthwhile. Furthermore, this extension was originally inspired by <https://bugs.winehq.org/show_bug.cgi?id=28869> but that was actually a different issue and was fixed another way. -Ken

March 4, 2014

Re: Assorted spelling fixes

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://newtestbot.winehq.org/JobDetails.pl?Key=5347 Your paranoid android. === w8 (32 bit crypt) === crypt.c:554: Test failed: got 11 expected ERROR_INVALID_PARAMETER

March 4, 2014