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

Re: registry keys of serial ports
by Uwe Bonnes Oct. 18, 2011

Oct. 18, 2011

Hello, while hunting down why a drop down box didn't offer me the serial port I configured, I stumbled across Stefans proposal from Summer 09. The patch still applied cleanly, and after setting up hal and the hal development library, the progarm worked as expected. What is the status of that proposal? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: po: Update English (US) translation
by Alexandre Julliard Oct. 18, 2011

Oct. 18, 2011

Ken Sharp <kennybobs(a)o2.co.uk> writes: > From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Sat, 15 Oct 2011 03:50:43 +0100 > Subject: [PATCH] po: Update English (US) translation There's no translation to update, the rc files are already en_US. If the strings need changing they have to be changed in the rc files. -- Alexandre Julliard julliard(a)winehq.org

4 10

Re: mshtml: Added IHTMLDocument2::elementFromPoint implementation
by Marvin Oct. 18, 2011

Oct. 18, 2011

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=14979 Your paranoid android. === TEST64_W7SP1 (32 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY" === TEST64_W7SP1 (64 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY"

2 1

Re: vbscript: Added support for hex literals not ending with '&'
by Marvin Oct. 18, 2011

Oct. 18, 2011

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=14970 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [4/7] wined3d: YUY2 and UYVY are block based
by Henri Verbeet Oct. 17, 2011

Oct. 17, 2011

On 16 October 2011 23:05, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + BOOL gl_compressed; I think the "gl_" prefix is somewhat questionable since the format being compressed or not is a property of the D3D format, it doesn't depend on what GL format we use, at least in the way the flag is currently used. You can change the meaning of the flag to be specific to the GL format, but then you'd have to set it in the format_texture_info[] table. > static const struct wined3d_format_compression_info format_compression_info[] = > { > - {WINED3DFMT_DXT1, 4, 4, 8}, > - {WINED3DFMT_DXT2, 4, 4, 16}, > - {WINED3DFMT_DXT3, 4, 4, 16}, > - {WINED3DFMT_DXT4, 4, 4, 16}, > - {WINED3DFMT_DXT5, 4, 4, 16}, > - {WINED3DFMT_ATI2N, 4, 4, 16}, > + {WINED3DFMT_DXT1, 4, 4, 8, TRUE }, > + {WINED3DFMT_DXT2, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT3, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT4, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT5, 4, 4, 16, TRUE }, > + {WINED3DFMT_ATI2N, 4, 4, 16, TRUE }, > + > + {WINED3DFMT_YUY2, 2, 1, 4, FALSE }, > + {WINED3DFMT_UYVY, 2, 1, 4, FALSE }, > }; If you decouple "block-based" and "compressed", it doesn't make sense anymore to set them in the same table like this. The "compressed" property should go to either the format_texture_info[] or the format_base_flags[] table, depending on whether it's considered a basic property of the format, or specific to the GL format we use for it. > + /* Block-based formats can't be rendered to with FBOs even if GL accepts them > + * (e.g. WINED3DFMT_YV12, which is just a GL_ALPHA texture). Even fragment shaders > + * can't account for that if a block is partially drawn. There's no such restriction on the GL side, the internal format just has to be color-renderable. The reason we can't render directly to these is because there a fixup associated with the format, but that has nothing to do with either being FBO-attachable or being block-based, and applies to e.g. P8 as well. > + * > + * Furthermore some drivers crash instead of generating an error if we attempt to > + * attach s3tc textures to an FBO */ This was an issue with some versions of fglrx, but should be fixed in current versions.

2 3

Still need patch review please (wineps.drv)
by Daniel Santos Oct. 17, 2011

Oct. 17, 2011

Of particular concern is making sure my dynamically allocated memory is being freed. The new data is stored in PSPEN and is allocated when SelectObject (on a wineps.drv device of course) passing a pen and is freed whenever a subsequent pen is selected or the device context is deleted. I'm just not intimately familiar enough with this part of the API to know for certain that this eliminates all room for leaks. Thanks! Daniel

1 1

Re: ntdll: avoid buffer overrun in lookup_manifest_file
by Alexandre Julliard Oct. 17, 2011

Oct. 17, 2011

Dan Kegel <dank(a)kegel.com> writes: > @@ -1877,7 +1877,7 @@ static WCHAR *lookup_manifest_file( HANDLE dir, struct assembly_identity *ai ) > if (build == min_build && revision < min_revision) continue; > tmp = strchrW(tmp, '_') + 1; > tmp = strchrW(tmp, '_') + 1; > - if (!strcmpiW( tmp, wine_trailerW )) > + if (!strncmpiW( tmp, wine_trailerW, dir_info->FileNameLength/sizeof(WCHAR) - (tmp - dir_info->FileName) )) That doesn't do the same thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Added lexer support for '_'
by Bruno Jesus Oct. 17, 2011

Oct. 17, 2011

On Fri, Oct 14, 2011 at 13:44, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/vbscript/lex.c | 10 ++++++++++ > dlls/vbscript/tests/lang.vbs | 7 +++++++ > dlls/vbscript/tests/run.c | 2 ++ > 3 files changed, 19 insertions(+), 0 deletions(-) > Hi, Jacek, I'm far away from my linux box and I'm just passing by to remember that there is a 24 continuation limit. Here is an invalid operation because it has 26 continuations: x = _ 3 _ + 3 _ + 3 _ + 3 _ + 3 - _ 3 + _ 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 And this is another test that must pass too (there is no new operand after the last _ ) : x = _ 3 _ + 3 _ + 3 _ + 3 _ As I said I can't test in wine but maybe you will find this information useful. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

2 2

Re: [3/7] d3d9/tests: Add a test for locking partial blocks with different pools
by Henri Verbeet Oct. 17, 2011

Oct. 17, 2011

On 16 October 2011 23:01, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 4, 4, 1, > + pools[i].pool == D3DPOOL_DEFAULT ? D3DUSAGE_DYNAMIC : 0, > + D3DFMT_DXT5, pools[i].pool, &texture, NULL); Same comment about dynamic textures as for patch 2/7. > + rect.left = 0; rect.top = 0; rect.right = 2; rect.bottom = 2; I don't care strongly about this, but note that SetRect() exists.

1 0

Re: [2/7] wined3d: Locking partial blocks is not allowed in DEFAULT pool resources
by Henri Verbeet Oct. 17, 2011

Oct. 17, 2011

On 16 October 2011 22:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 128, 128, 1, D3DUSAGE_DYNAMIC, dxt_formats[i].fmt, > + D3DPOOL_DEFAULT, &texture, NULL); You should check D3DCAPS2_DYNAMICTEXTURES before using dynamic textures. Also, wouldn't it be more appropriate to make this part of the test in patch 3/7?

1 0