July 2010 - Wine-devel - list.winehq.org

Re: winhlp32: Remove an untranslated resource from multiple translations.
by Dmitry Timoshkov 12 Jul '10

12 Jul '10

Michael Stefaniuc <mstefani(a)redhat.de> wrote: > This affects the Bg, Cs, Da, Eo, Fi, Hu, Sk, Tr and Wa translations. It's better to have it, even not translated. String resources should be fully filled up. Why do remove this one and leave the others? -- Dmitry.

2 1

Request: please add your expertise to the release announcement!
by Scott Ritchie 12 Jul '10

12 Jul '10

Alexandre has said -rc7 is likely to be the last rc before release, which means we're quickly running out of time to get a good release announcement. Please add whatever you think might be interesting to the wiki page. It's ok if it's not a complete sentence at this point, I can clean that stuff up myself -- what the page really needs is content. http://wiki.winehq.org/Wine1.2Announcement In particular, we need examples of new platinum-quality apps and new neat technical features you're proud of. Thanks, Scott Ritchie

2 1

Re: List of Video cards in directx.c
by Seth Shelnutt 12 Jul '10

12 Jul '10

On Sun, Jul 11, 2010 at 4:21 PM, Roderick Colenbrander < thunderbird2k(a)gmail.com> wrote: > > The PCI id is something else. For instance run 'lspci -x': > 01:00.1 Audio device: ATI Technologies Inc RV620 Audio device [Radeon > HD 34xx Series] > 00: 02 10 28 aa 07 01 10 40 00 00 03 04 10 00 80 00 > .. > > This line shows a part of the PCI configuration header. The first two > bytes contain the PCI vendor id (0x1002 = ATI; you have to swap the > bytes) and byte 3 and 4 contain the PCI device id (0xaa28 = radeon > 3450). Each device has such information and it is used by the > operating system to detect which hardware is around. > > A lot of games use the PCI id, since it can be easier to parse than > the renderer strings. > > That makes sense. I had based my thinking on the following comment, A Direct3D device object contains the PCI id (vendor + device) of the videocard which is used for rendering. I had assumed vendor + device meant the strings. > We have to keep the current static database. Extending it with video > memory reporting is likely the best way to go. So now and then it just > means that we have to refine it a little. > > Roderick > Thinking things over I think you are right. Trying to add any kind of dynamic support at this stage is not worth it. Even the memory reporting is very recent and new. Maybe in a couple years more support will have materialized from opengl or the drivers to help with this issue. For now though I just submitted a patch to deal with the issue of a 8500/8400 being reported as a 8300. I moved the detection to be reported as an 8600. I thought about creating a new 8500 in the database but I realized that an 8600 is of feature parity and has the same video memory minimum. Thanks, Seth Shelnutt

1 0

Re: shlwapi: Partially implement SHGetShellKey (try5)
by testbot＠testbot.winehq.org 11 Jul '10

11 Jul '10

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 http://testbot.winehq.org/JobDetails.pl?Key=3283 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:595: Test failed: GetShellSecurityDescriptor should fail ordinal.c:618: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1761: Test failed: got 13 ordinal.c:1782: Test failed: got 10 ordinal.c:1795: Test failed: got 13 ordinal.c:1803: Test failed: got 13 ordinal.c:1833: Test failed: got 37, length 38 ordinal.c:1844: Test failed: got 40 ordinal.c:1855: Test failed: got 23 ordinal.c:1866: Test failed: got 26 === W7PROX64 (32 bit ordinal) === ordinal.c:1774: Test failed: got 12 ordinal.c:1810: Test failed: got 12 ordinal.c:1855: Test failed: got 20 ordinal.c:1866: Test failed: got 23 === W7PROX64 (64 bit ordinal) === ordinal.c:1761: Test failed: got 10 ordinal.c:1767: Test failed: got 23 ordinal.c:1782: Test failed: got 7 ordinal.c:1795: Test failed: got 10 ordinal.c:1803: Test failed: got 10 ordinal.c:1817: Test failed: got 23 ordinal.c:1825: Test failed: got 23 ordinal.c:1833: Test failed: got 32, length 33 ordinal.c:1844: Test failed: got 35 ordinal.c:1855: Test failed: got 20 ordinal.c:1866: Test failed: got 23

1 0

List of Video cards in directx.c
by Seth Shelnutt 11 Jul '10

11 Jul '10

I'm not sure if this is appropriate for a code freeze or not but I think it is. We just ran into an issue with the folding gpu client in wine with someone. Turns out it's because wine reports the card as a 8300 not an 8500. Looking at directx.c I see that that is probably because an 8500 is not listed. I've got a patch to add the single line for 8500 but I was wondering, would it not be beneficial to add a list of all graphic cards dating back to a certain point? There are even less ATI cards listed than Nvidia. All that is required is going to say wikipedia or Nvidia/Ati.com and just go through the list of the cards. Thanks, Seth Shelnutt

5 6

sorry one more question: assert statements in tests
by Misha Koshelev 10 Jul '10

10 Jul '10

I am implementing my tests as follows: * patch 1: general test for a D3DX function (D3DXCreateBox for example, testing specific vertices and indices for _specific_ dimensions). * patch 2: separate into function that works with arbitrary dimensions for the box, etc. I restrict to the dimensions from patch 1 using assert statements. * patch 3: expand to allow arbitrary parameters to the function, e.g., arbitrary dimensions, removing the assert statements. For example, see patch 2 = http://github.com/misha680/wine/commit/6291ca28593c78761ccef3137b1014bae87d… patch 3 = http://github.com/misha680/wine/commit/7b09cfb661bf1d03fd80195c0cd2b7b3bb9f… Is assert the right way to do this? If not, what is? Thank you Misha

2 5

Inserting commits fyi... I think this might do the trick
by Misha Koshelev 10 Jul '10

10 Jul '10

Thank you all for your comments. I still seem to be losing commits. However I have found a reference that seems like it might do the trick and wanted to share with others. Specifically, the key is to mark edit in interactive rebase on the commit one desires to split. Next one does a git reset HEAD^ to revert the commit. Then, one can create one or more commits without the --amend parameter. Finally one does git rebase --continue Sorry if this is already known to all of you but I have been chasing disappearing commits for a few days now and this seems like quite useful knowledge. Misha http://book.git-scm.com/4_interactive_rebasing.html

1 0

git rebase to _insert_ commits?
by Misha Koshelev 10 Jul '10

10 Jul '10

Dear All: I am still learning git and it seems that my solution does not quite work. Specifically, my idea was to use: git rebase -i upstream/master Mark the commit _after_ which I'd like to insert a commit with edit. Then, when I am at that commit, I do: git commit --amend -a save commit Then, _before_ doing git rebase --continue, I edit files and again do: git commit -a -n Finally I do: git rebase --continue The problem is that this seems to squish further commits, and leads to problems which I am now trying to untangle. However, as I still cannot insert a commit, I am not sure how to proceed, except by creating a whole new repository. Any ideas/hints? Thank you Misha

2 2

Re: wined3d: Add GL_NV_point_sprite extension.
by Henri Verbeet 10 Jul '10

10 Jul '10

2010/7/10 Rico Schüller <kgbricola(a)web.de>: > + if ((!context->gl_info->supported[WINED3D_GL_VERSION_2_0] > + || (!glPointParameteri && context->gl_info->supported[WINED3D_GL_VERSION_2_0] > + && !context->gl_info->supported[NV_POINT_SPRITE]) ) The second "context->gl_info->supported[WINED3D_GL_VERSION_2_0]" is redundant.

1 0

please don't shoot from the hip ;)
by Misha Koshelev 10 Jul '10

10 Jul '10

Hi Guys: I really appreciate all the responses to my work on this bug http://bugs.winehq.org/show_bug.cgi?id=22918 Especially the fact that you guys are looking at this code is very very important to me, as it will have to be eventually reviewed to be submitted to Wine. However, I am a little frustrated as the comments I received were things already discussed on wine-devel. I find myself in quite the lucky position that I can work on Wine for some time. I do this with no economic compensation of any kind (as I guess most of you as well - except Codeweavers people grin ;) - oh and full disclosure with the exception of a book on DirectX and hopefully a trip to WineConf ;) ). However, I'd like to spend the time actually coding, not referencing wine-devel. In any case, I'd appreciate it if you have a comment on my code/patches, esp if it might have already been discussed on wine-devel, please don't "shoot from the hip" and check wine-devel first... Anyway enough venting. Off to work. Again I appreciate the attention to my patches. Misha

3 2