June 2011 - Wine-Devel - list.winehq.org

Re: dxgi.idl: Added DXGI_SWAP_CHAIN_FLAG enum declaration and DXGI_MWA_* flags

by Henri Verbeet

On 30 June 2011 17:34, Jacek Caban <jacek(a)codeweavers.com> wrote: > +cpp_quote("#define DXGI_MWA_NO_WINDOW_CHANGES 0x1") > +cpp_quote("#define DXGI_MWA_NO_ALT_ENTER 0x2") > +cpp_quote("#define DXGI_MWA_NO_PRINT_SCREEN 0x4") > +cpp_quote("#define DXGI_MWA_VALID 0x7") Aren't those usually done as constants? (I.e., "const UINT DXGI_MWA_NO_WINDOW_CHANGES = 0x1;")

June 30, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/30/2011 06:07 PM, Vincas Miliūnas wrote: > On 06/30/2011 05:57 PM, wylda(a)volny.cz wrote: >>> $ cd wine-git >>> $ wget http://dl.dropbox.com/u/6901628/raw.patch >>> $ patch -p1 < raw.patch >>> $ ./tools/make_requests >>> $ ./configure >>> $ make >>> >>> works here: >> Thanks Austin for testing, but this raw.patch is already modified >> and works for me too. I would need to retest the series of nine >> individial patches ;) (thoses in wine-patches queue with >> status=New). >> >> But it looks like Vincas already know where the problem is :-) >> >> Regards, >> W. >> >> >> > Austin just reported that I do not :) > > Another thing that would be helpful would be to get the exact > modifications that are applied to the source tree (not only the patches > but also the products of code generation from server/protocol.def). > > So with the non-compiling code, execute these commands: > git add . > git diff origin/master > mod.patch > > Add send the mod.patch file, maybe that will reveal the secret. > Ahh, just looked again and saw that I assumed wrong. Austin ran the http://dl.dropbox.com/u/6901628/raw.patch (with the modified header, that is intended to be fixed), not the http://dl.dropbox.com/u/6901628/bug_test.patch test-case, that should validate that the 32bit gcc WINE build is broken. (also the topic is about bug 27600, but you do not need this patch to reproduce it, left/right-clicking repositions the mouse cursor) (also applying patch http://source.winehq.org/patches/data/75733 fixes one regression, where the game hangs)

June 30, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/30/2011 05:57 PM, wylda(a)volny.cz wrote: >> $ cd wine-git >> $ wget http://dl.dropbox.com/u/6901628/raw.patch >> $ patch -p1 < raw.patch >> $ ./tools/make_requests >> $ ./configure >> $ make >> >> works here: > Thanks Austin for testing, but this raw.patch is already modified > and works for me too. I would need to retest the series of nine > individial patches ;) (thoses in wine-patches queue with > status=New). > > But it looks like Vincas already know where the problem is :-) > > Regards, > W. > > > Austin just reported that I do not :) Another thing that would be helpful would be to get the exact modifications that are applied to the source tree (not only the patches but also the products of code generation from server/protocol.def). So with the non-compiling code, execute these commands: git add . git diff origin/master > mod.patch Add send the mod.patch file, maybe that will reveal the secret.

June 30, 2011

Re: wine bug 27600

by wylda＠volny.cz

> > $ cd wine-git > $ wget http://dl.dropbox.com/u/6901628/raw.patch > $ patch -p1 < raw.patch > $ ./tools/make_requests > $ ./configure > $ make > > works here: Thanks Austin for testing, but this raw.patch is already modified and works for me too. I would need to retest the series of nine individial patches ;) (thoses in wine-patches queue with status=New). But it looks like Vincas already know where the problem is :-) Regards, W.

June 30, 2011

Re: wine bug 27600

by Matijn Woudt

On Thu, Jun 30, 2011 at 4:52 PM, Austin English <austinenglish(a)gmail.com> wrote: > 2011/6/30 <wylda(a)volny.cz>: >>> Ok, try with a modified header: >>> >> >> OK no problem, i will try later today. But i don't think it's a bug >> in applicability of those patches. I began with wine testing 2 years >> ago and did many regression tests, reverse reg.testing, found faulty >> commit even though it was covered by several other faulty commits >> etc. >> >> I think I can find a problem between patches quite well. I can't go >> under "patch level" aka go into lines of code and that's the helping >> hand i would need here, i.e. i know, that 3rd patch of your series >> makes troubles to me and i also know, that your one big merged and >> modified patch works for me. Unfortunately as i said, i can't search >> a regression between lines of code. And this is a place we should >> look in, i guess... >> >> Sure, i will try again your modified script later today and let you >> know. >> >> For the other guys, could i call for help?? Could you please try to >> apply the Vincas's 9 patch raw-input series to the current git, try >> to compile and let me know, if you succeed? I really would like to >> know if i'm the only one with such problem. >> >> Thank you all, >> W. > > $ cd wine-git > $ wget http://dl.dropbox.com/u/6901628/raw.patch > $ patch -p1 < raw.patch > $ ./tools/make_requests > $ ./configure > $ make > > works here: > austin(a)debian:~/wine-git$ cat /etc/issue > Debian GNU/Linux wheezy/sid \n \l > > austin(a)debian:~/wine-git$ uname -a > Linux debian 2.6.39-2-686-pae #1 SMP Wed Jun 8 11:33:14 UTC 2011 i686 GNU/Linux > > -- > -Austin Wylda already reported that this big patch worked, but the 9-patch series didn't. Can you try those?

June 30, 2011

Re: wine bug 27600

by Austin English

2011/6/30 <wylda(a)volny.cz>: >> Ok, try with a modified header: >> > > OK no problem, i will try later today. But i don't think it's a bug > in applicability of those patches. I began with wine testing 2 years > ago and did many regression tests, reverse reg.testing, found faulty > commit even though it was covered by several other faulty commits > etc. > > I think I can find a problem between patches quite well. I can't go > under "patch level" aka go into lines of code and that's the helping > hand i would need here, i.e. i know, that 3rd patch of your series > makes troubles to me and i also know, that your one big merged and > modified patch works for me. Unfortunately as i said, i can't search > a regression between lines of code. And this is a place we should > look in, i guess... > > Sure, i will try again your modified script later today and let you > know. > > For the other guys, could i call for help?? Could you please try to > apply the Vincas's 9 patch raw-input series to the current git, try > to compile and let me know, if you succeed? I really would like to > know if i'm the only one with such problem. > > Thank you all, > W. $ cd wine-git $ wget http://dl.dropbox.com/u/6901628/raw.patch $ patch -p1 < raw.patch $ ./tools/make_requests $ ./configure $ make works here: austin(a)debian:~/wine-git$ cat /etc/issue Debian GNU/Linux wheezy/sid \n \l austin(a)debian:~/wine-git$ uname -a Linux debian 2.6.39-2-686-pae #1 SMP Wed Jun 8 11:33:14 UTC 2011 i686 GNU/Linux -- -Austin

June 30, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 06/30/2011 05:31 PM, wylda(a)volny.cz wrote: >> Ok, try with a modified header: >> > OK no problem, i will try later today. But i don't think it's a bug > in applicability of those patches. I began with wine testing 2 years > ago and did many regression tests, reverse reg.testing, found faulty > commit even though it was covered by several other faulty commits > etc. > > I think I can find a problem between patches quite well. I can't go > under "patch level" aka go into lines of code and that's the helping > hand i would need here, i.e. i know, that 3rd patch of your series > makes troubles to me and i also know, that your one big merged and > modified patch works for me. Unfortunately as i said, i can't search > a regression between lines of code. And this is a place we should > look in, i guess... > > Sure, i will try again your modified script later today and let you > know. > > For the other guys, could i call for help?? Could you please try to > apply the Vincas's 9 patch raw-input series to the current git, try > to compile and let me know, if you succeed? I really would like to > know if i'm the only one with such problem. > > Thank you all, > W. > > > Well, I am almost certain what the problem is :) I think that you have a 32bit OS (well, the ./configure logs could tell me that). I and the WINE's testbot builder run 64bit OSes, the people from bug 20395 (also a person in #winehq) that compiled and ran the patch successfully most likely also run 64bit OSes, thus 64bit version of gcc by default. The issue is on i386, where a certain include-file combination that is used is hitting this "expected declaration specifiers or ‘...’" bug for __ms_va_list. I wrote a small test-case patch, that should fail to compile using 32bit gcc - http://dl.dropbox.com/u/6901628/bug_test.patch If it fails, it's most likely a WINE bug and should be filed to bugzilla. As a solution to workaround that, I will add those unused include statements (as is a similar story with user.h) for it compile on i386; will submit once I've finished some new features. Thanks for discovering this :)

June 30, 2011

Re: wine bug 27600

by wylda＠volny.cz

> Ok, try with a modified header: > OK no problem, i will try later today. But i don't think it's a bug in applicability of those patches. I began with wine testing 2 years ago and did many regression tests, reverse reg.testing, found faulty commit even though it was covered by several other faulty commits etc. I think I can find a problem between patches quite well. I can't go under "patch level" aka go into lines of code and that's the helping hand i would need here, i.e. i know, that 3rd patch of your series makes troubles to me and i also know, that your one big merged and modified patch works for me. Unfortunately as i said, i can't search a regression between lines of code. And this is a place we should look in, i guess... Sure, i will try again your modified script later today and let you know. For the other guys, could i call for help?? Could you please try to apply the Vincas's 9 patch raw-input series to the current git, try to compile and let me know, if you succeed? I really would like to know if i'm the only one with such problem. Thank you all, W.

June 30, 2011

Re: GSoC: dinput8 Action Mapping

by Marcus Meissner

On Thu, Jun 30, 2011 at 02:56:08AM -0300, Lucas Zawacki wrote: > Hey guys, how are you doing? I've got some patches for you. > > The first is a refactoring of the BuildActionMap implementations for > keyboard and mouse. I think with 'semantic_to_obj_id' the mapping is > pretty much correct for keyboard and mouse and it's being done "the > right way". > > The second patch is much like one I sent some time ago, it's > SetActionMap for keyboard and mouse, this time (hopefully) with the > dataformat stuff done right too. I've split it up in a third patch, > which implements the "action mapping" per se. > > Anyway, tomorrow I'll code some mouse tests to be sure that this is working. > > Cheers > From 37e5a1e6d51778ee0d5c0f3081dad8ca1431968f Mon Sep 17 00:00:00 2001 > From: Lucas Fialho Zawacki <lfzawacki(a)gmail.com> > Date: Fri, 10 Jun 2011 21:43:53 -0300 > Subject: dinput: Keyboard and mouse implementation of BuildActionMap (try 4) > > > +DWORD semantic_to_obj_id(IDirectInputDeviceImpl* This, DWORD dwSemantic) > +{ ... > + if (!found) return 0; So 0 is the not found case... > + DWORD obj_id = semantic_to_obj_id(&This->base, lpdiaf->rgoAction[i].dwSemantic); > + if (obj_id != -1) But here you check for -1. > + DWORD obj_id = semantic_to_obj_id(&This->base, lpdiaf->rgoAction[i].dwSemantic); > + if (obj_id != -1) and here. (both mouse and keyboard code) should probably check for 0 there, also as DWORD is unsigned ;) Ciao, Marcus

June 30, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Henri Verbeet

On 30 June 2011 14:49, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > In init_edge_face_map I initialize an array of edge_face structs, and > in find_adjacent_face I do a linear search through that array. I would > like to replace the array with a hash table, so that the search time > becomes constant. I've found a standard list (wine/list.h) and > red-black tree implementation (wine/rbtree.h), but not a standard hash > table implementation. Is there a standard hash table implementation, > should I roll my own or find an LGPL'ed one? > I'm not sure if a hash table would be faster and how much, but an easy way to make the lookup cheaper would be to store the edge -> face map as a list for each vertex. So e.g. if you have these faces: f0: v0, v2, v1 f1: v1, v4, v3 f2: v1, v2, v4 f3: v2, v5, v4 You'd build these lists: v0: {v2:f0} v1: {v0:f0}, {v4:f1}, {v2:f2} v2: {v1:f0}, {v4:f2}, {v5:f3} v3: {v1:f1} v4: {v3:f1}, {v1:f2}, {v2:f3} v5: {v4:f3} It's then mostly trivial to determine adjacency. This assumes most vertices are only part of a handful of edges, but I don't think that's unreasonable in practice. We did have a hash table inside wined3d at some point, I suppose you could also try resurrecting that from git history.

June 30, 2011