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

Re: [PATCH 1/5] d3d9/tests: Use a separate device for test_vshader_input().

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=5937 Your paranoid android. === w8 (32 bit visual) === visual.c:7297: Test failed: Input test: Quad 2(1crd) returned color 0x00000000, expected 0x00ffff00 visual.c:7282: Test failed: Input test: Quad 2(1crd) returned color 0x00000000, expected 0x00ffff00 visual.c:7282: Test failed: Input test: Quad 2(1crd) returned color 0x00000000, expected 0x00ffff00

March 25, 2014

Re: Wine test week 2 - nice apparent progress

by Henri Verbeet

On 25 March 2014 01:00, Jeremy White <jwhite(a)codeweavers.com> wrote: > My script results are here: > http://www.winehq.org/~jwhite/ebd5f96aea22.html > For what it's worth, note that the intermittent failures in ddraw:ddraw7 are timeouts, and happening in different places. I suspect that's either the generic issue of the testbot timing out on occasion, or the testbot just not being fast enough to finish the test in time, perhaps due to it being under some load from a different VM.

March 25, 2014

Re: riched20/tests: Add tests for ITextDocument::Open about dealing with rtf. (try 2)

by Jactry Zeng

Hi, 2014-03-19 21:14 GMT+08:00 Nikolay Sivov <bunglehead(a)gmail.com>: > > On 3/19/2014 17:02, Jactry Zeng wrote: > >> + /* open a rtf without } in the end */ >> + result = ITextDocument_Open(txtDoc, &testfile, tomReadOnly, CP_ACP); >> + /* 0x80070026 is HRESUILT_FROM_WIN32(ERROR_HANDLE_EOF) */ >> + todo_wine ok(result == 0x80070026, "ITextDocument_Open: Should return an ERROR_HANDLE_EOF error.\n"); > > No need to put a magic number, use HRESULT_FROM_WIN32(), Using HRESULT_FROM_WIN32() we should include Winerror.h, so I give this way up in this patch. I will continue improving this patch. Thanks for your review! -- Regards, Jactry Zeng

March 25, 2014

Re: wintab: Incorrectly classifying cursor as stylus instead of eraser

by John Klehm

Found another oddball log: http://www.winehq.org/pipermail/wine-devel/2013-May/099905.html I don't have any suggestions on what the right solution is... just wanted to make sure you had all the logs. Regards, --John On Sat, Mar 22, 2014 at 12:28 PM, John Klehm <xixsimplicityxix(a)gmail.com>wrote: > Hello, > > > >To be able to prioritize we have to change current functions into smth > like this: > > >get_cursor_type(cursor) { //new function > > can we determine type based on cursor.device? Yes -> return > CSR_TYPE_PEN; > > can we determine type based on cursor.name? Yes -> return > CSR_TYPE_ERASER; > > return CSR_TYPE_OTHER; > >} > > I worked on this code a little bit back in the day, I remember the > detection stuff getting weird due to some odd ball drivers (non-wacom stuff > doing strange things). > > Bug http://bugs.winehq.org/show_bug.cgi?id=11699 and specifically the log > http://bugs.winehq.org/attachment.cgi?id=13358 of an Acecad table > driver's settings. > > Just thought it might be handy to consider if you were to take a shot at > rewriting the detection code. > > Regards, > --John > > > On Fri, Mar 21, 2014 at 4:09 AM, Michael Stefaniuc <mstefani(a)redhat.com>wrote: > >> On 03/21/2014 10:04 AM, Eriks Dobelis wrote: >> > To be able to prioritize we have to change current functions into smth >> > like this: >> > >> > get_cursor_type(cursor) { //new function >> > can we determine type based on cursor.device? Yes -> return >> > CSR_TYPE_PEN; >> > can we determine type based on cursor.name? Yes -> return >> > CSR_TYPE_ERASER; >> > return CSR_TYPE_OTHER; >> > } >> > >> > and rewriting is_stylus and is_eraser into more simple functions like >> > is_stylus(cursor) { >> > return get_cursor_type(cursor) == CSR_TYPE_PEN; >> > } >> In that case you could actually get rid of the is_* functions; >> "get_cursor_type(cursor) == CSR_TYPE_PEN" is as readable. >> >> bye >> michael >> >> > >> > >> > On 2014.03.21. 10:54, Alexandre Julliard wrote: >> >> Eriks Dobelis <eriks.dobelis(a)biti.lv> writes: >> >> >> >>> The alternative - just to switch order of checks in >> >>> X11DRV_LoadTabletInfo. There is a code fragment: >> >>> /* prefer finding TYPE_PEN(most capable) */ >> >>> if (is_stylus(target->name, device_type)) >> >>> cursor.TYPE = CSR_TYPE_PEN; >> >>> else if (is_eraser(target->name, device_type)) >> >>> cursor.TYPE = CSR_TYPE_ERASER; >> >>> else >> >>> cursor.TYPE = CSR_TYPE_OTHER; >> >>> >> >>> I would need to switch order and check for ERASER first. Problems >> >>> would arise if for some device name would be "Pen & Eraser", and type >> >>> would be "STYLUS" , and then it would be detected as eraser. In the >> >>> proposed patch this problem would not arise as only device is checked >> >>> for ERASER. For my specific case both approaches work. Which one you >> >>> consider as better? >> >> Maybe a better way would be to restructure the checks, and give >> priority >> >> to the type over the name or something like that. The thing is that we >> >> don't want to have an is_stylus function that also checks for erasers, >> >> and then an is_eraser function with slightly different checks. >> >> >> > >> > >> > >> >> >> -- >> Michael Stefaniuc Tel.: +49-711-96437-199 >> Supervisor, APAC/EMEA IT Network Fax.: +49-711-96437-111 >> -------------------------------------------------------------------- >> Reg. Adresse: Red Hat GmbH, Werner-von-Siemens-Ring 14, 85630 Grasbrunn >> Handelsregister: Amtsgericht Muenchen HRB 153243 >> Geschäftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, >> Charles Cachera >> >> >> >

March 25, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Ken Thomases

On Mar 24, 2014, at 7:48 PM, Christopher Thielen wrote: > Using WINEDEBUG=+all, the resource in question (static/bitmap16.flx) is loaded via kernel32's CreateFile, ReadFile. > > Is there a way to trace only kernel32 calls dealing with a specific file handle? I'm curious if there are any failed reads. Does that seem like a reasonable next step? Not really. You'll want to use a +file log and follow the handle as it's passed to subsequent calls. It might also be necessary to use +tid,+relay to see all uses if Wine isn't logging the handle in all relevant functions. Certainly, look for failed reads, but I wouldn't expect that unless you think the file is damaged vs. what's installed on Windows. More likely, the game requires external help interpreting the data that is has read, like a compression or image library. If that's not present or is incomplete in Wine, then that would explain the problem. The +tid,+relay log may help to identify what the program does next after it has read the data in. -Ken

March 25, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

Using WINEDEBUG=+all, the resource in question (static/bitmap16.flx) is loaded via kernel32's CreateFile, ReadFile. Is there a way to trace only kernel32 calls dealing with a specific file handle? I'm curious if there are any failed reads. Does that seem like a reasonable next step? On 03/24/2014 03:34 PM, Christopher Thielen wrote: > That was exactly the problem - didn't read carefully enough. > > Using Wine's D3D9 implementation on Windows XP, the missing cursor > _does_ show up, so this Wine bug is likely not a D3D issue. > > I did find some old fan-created tools which can extract the resources > from the game's proprietary formats. > > As there are no failed CreateSurface/CreateTexture calls, I'm assuming > the code path never gets to that point. > > Any ideas on how to go about debugging the problem of a custom file type > not getting loaded? Does Wine implement it's own libc in which one could > perhaps trace fread(), etc.? From the fan-made tools, I do have the byte > offsets within the proprietary format where the missing cursor should be > loaded from. > > Also, is there any likely reason why Wine's behavior might differ from > Windows on operations which are relatively libc-style operations? > > On 3/24/2014 1:14 PM, Stefan Dösinger wrote: >> Am 24.03.2014 um 18:53 schrieb Christopher Thielen >> <christopher(a)thielen.co>: >>> I then tried cross-compiling Wine from Linux using MinGW. I copied >>> over the resulting d3d9.dll and wined3d.dll to the game's directory >>> on Windows XP but it then won't run, complaining: >>> >>> "The procedure entry point __wine_get_wgl_driver could not be located >>> in the dynamic link library gdi32.dll.“ >> Did you set CFLAGS=-DUSE_WIN32_OPENGL ? This preprocessor define is >> needed to make wined3d work on Windows. Otherwise it uses some >> Wine-specific exports to bypass opengl32.dll for non-WGL calls and >> calls libGL.so directly for performance reasons. >> > > >

March 25, 2014

Wine test week 2 - nice apparent progress

by Jeremy White

My script results are here: http://www.winehq.org/~jwhite/ebd5f96aea22.html We had a lot of tests that had failed on Windows 7 ultimate that we now skip; that has reduced the number of apparent failures on the new testbot machines down under 20. We've also had some nice work from folks like Dmitry (thanks!). I'll keep annotating the failures until they all have notes. I do have one that could use a sucker^H^H^H^H^H^Hvolunteer: http://test.winehq.org/data/ebd5f96aea22f4093d4ceb109bdead2657666c57/xp_new… I had asked Misha Koshelev (the apparent last person to meaningfully change those tests) if he wanted to look into it, but he's in the middle of a medical internship working brutal hours, so he demurred. Cheers, Jeremy

March 25, 2014

Re: user32: Fix side effect in SubtractRect()

by Javier Cantero

On Sun, Mar 23, 2014 at 12:18:04AM +0400, Nikolay Sivov wrote: > That means we don't have any tests for it yet, so feel free to add > test_SubtractRect(). Maybe a better idea is to do two separate patches: - First one with some basic conformance test cases for SubtractRect() (create the skeleton and verify that the test is well written and working) - Then (after the merge of the previous one) another with the fix and the test case that covers the fix added to the tests I can send the first patch tomorrow if there is no objection.

March 24, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Christopher Thielen

That was exactly the problem - didn't read carefully enough. Using Wine's D3D9 implementation on Windows XP, the missing cursor _does_ show up, so this Wine bug is likely not a D3D issue. I did find some old fan-created tools which can extract the resources from the game's proprietary formats. As there are no failed CreateSurface/CreateTexture calls, I'm assuming the code path never gets to that point. Any ideas on how to go about debugging the problem of a custom file type not getting loaded? Does Wine implement it's own libc in which one could perhaps trace fread(), etc.? From the fan-made tools, I do have the byte offsets within the proprietary format where the missing cursor should be loaded from. Also, is there any likely reason why Wine's behavior might differ from Windows on operations which are relatively libc-style operations? On 3/24/2014 1:14 PM, Stefan Dösinger wrote: > Am 24.03.2014 um 18:53 schrieb Christopher Thielen <christopher(a)thielen.co>: >> I then tried cross-compiling Wine from Linux using MinGW. I copied over the resulting d3d9.dll and wined3d.dll to the game's directory on Windows XP but it then won't run, complaining: >> >> "The procedure entry point __wine_get_wgl_driver could not be located in the dynamic link library gdi32.dll.“ > Did you set CFLAGS=-DUSE_WIN32_OPENGL ? This preprocessor define is needed to make wined3d work on Windows. Otherwise it uses some Wine-specific exports to bypass opengl32.dll for non-WGL calls and calls libGL.so directly for performance reasons. >

March 24, 2014

Re: Advice fixing #13683 (DirectX mouse overlay?)

by Stefan Dösinger

Am 24.03.2014 um 18:53 schrieb Christopher Thielen <christopher(a)thielen.co>: > I then tried cross-compiling Wine from Linux using MinGW. I copied over the resulting d3d9.dll and wined3d.dll to the game's directory on Windows XP but it then won't run, complaining: > > "The procedure entry point __wine_get_wgl_driver could not be located in the dynamic link library gdi32.dll.“ Did you set CFLAGS=-DUSE_WIN32_OPENGL ? This preprocessor define is needed to make wined3d work on Windows. Otherwise it uses some Wine-specific exports to bypass opengl32.dll for non-WGL calls and calls libGL.so directly for performance reasons.

March 24, 2014