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

Re: [PATCH 4/8] jscript: Added bytecode version of try statement

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 http://testbot.winehq.org/JobDetails.pl?Key=16180 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

Dec. 28, 2011

Re: [PATCH 2/7] wined3d: Move srgb checks away from d3dfmt_get_conv.

by Henri Verbeet

On 26 December 2011 05:32, Diego Nieto Cid <dnietoc(a)gmail.com> wrote: > trace:d3d_surface:surface_allocate_surface (0x1a25f0) : Creating surface (target 0xde1) level 0, d3d format WINED3DFMT_P8_UINT, internal format 0x80e5, width 1024, height 512, gl format 0x1908, gl type=0x1401 > err:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexImage2D @ surface.c / 2571 > Does your hardware really support EXT_paletted_texture? That's somewhat unusual. > It's located in d3dfmt_get_conv under the WINED3DFMT_P8_UINT case. For > some reason only glInternal is updated by the conversion. In any case it > didn't matter before the patch as none of the internal values were > actually used in case a conversion was applied. > > Should the three internal values be updated by the conversion now that > any of them could be used? Probably, yeah. Not just for WINED3DFMT_P8_UINT, but for all the formats in d3dfmt_get_conv(). I guess something like the following at the end of d3dfmt_get_conv() should work: if (*convert != NO_CONVERSION) { format->glGammaInternal = format->glInternal; format->rtInternal = format->glInternal; } > Even if it would work I'm not sure how > correct would be to do that. > The whole surface conversion code is pretty ugly and fragile, unfortunately.

Dec. 28, 2011

Re: cscript: Add forwarder to wscript

by Jacek Caban

On 12/27/11 7:24 PM, Jacek Caban wrote: > On 12/27/11 7:00 PM, André Hentschel wrote: >> The difference between cscript and wscript is that wscipt should show >> a propertysheet and cscritp is console only, but our wscript doesn't >> show a propertysheet... > > It doesn't show a propertysheet yet, that's to be fixed. Forwarding > one to another was always planned, but we need a way to switch modes. > There is a command line switch to do it (//H:CScript and //H:WScript). > AFAIR it didn't really work when I've tried it, but even if it's > broken on Windows, we may still consider using it for our forwarding. I spoke too fast. //H:* options are for registry changes, so it's not relevant here. //B remains as an option. Jacek

Dec. 27, 2011

Re: cscript: Add forwarder to wscript

by Jacek Caban

On 12/27/11 7:00 PM, André Hentschel wrote: > The difference between cscript and wscript is that wscipt should show a propertysheet and cscritp is console only, but our wscript doesn't show a propertysheet... It doesn't show a propertysheet yet, that's to be fixed. Forwarding one to another was always planned, but we need a way to switch modes. There is a command line switch to do it (//H:CScript and //H:WScript). AFAIR it didn't really work when I've tried it, but even if it's broken on Windows, we may still consider using it for our forwarding. Maybe just passing //B option would be good enough. Otherwise we'd need a Wine-specific way for informing wscript that it should behave like cscript. Differences are not too big, be we need a plan to address them. Jacek

Dec. 27, 2011

Re: wininet: add a stub for DeleteWpadCacheForNetworks

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > +BOOL WINAPI DeleteWpadCacheForNetworks(int WPAD_CACHE_DELETE) Parameter name and type are completely wrong. > +{ > + FIXME(": stub\n"); > + return FALSE; > +} ... > +typedef enum{ > + WPAD_CACHE_DELETE_CURRENT = 0x0, > + WPAD_CACHE_DELETE_ALL = 0x1 > +} WPAD_CACHE_DELETE; -- Dmitry.

Dec. 27, 2011

Re: PLT Problems with Wine/Sparc

by Austin English

2011/12/26 André Hentschel <nerv(a)dawncrow.de>: > Hi, > thanks to Austin i could work on our sparc port and it seems i have it it a workable state, > the remaining problem is that somehow the plt entry to libwine is fixed up wrong. > I know most people on the list don't know much about sparc, so wild guesses are all i want. > > --- snip --- > readelf -r: > 0002c988 00003315 R_SPARC_JMP_SLOT 00000000 wine_dbg_log + 0 > > objdump -D: > 0002c988 <wine_dbg_log(a)plt>: > 2c988: 03 00 00 78 sethi %hi(0x1e000), %g1 > 2c98c: 30 bf ff e1 b,a 2c910 <_PROCEDURE_LINKAGE_TABLE_> > 2c990: 01 00 00 00 nop > > gdb: > 0xf66957e0 <+288>: call 0xf66a8988 <wine_dbg_log(a)plt> > (gdb) printf "%08x\n", (void*)*0xf66a8988 > 033dfa34 > (gdb) printf "%08x\n", (void*)*0xf66a898C > 81c06200 > (gdb) printf "%08x\n", (void*)*0xf66a8990 > 01000000 > (gdb) > --- /snip (also available as http://pastebin.com/JFN2w6q2 if bad format) --- > > it crashes (SIGSEGV) at wine_dbg_log(a)plt (0xf66a8988) in imm32.dll.so > (if i remove the TRACE from DllMain it continues to crash with other libwine functions in winex11) > > 033dfa34 seems like a wrongly fixed up opcode to me. What do you guess? > Should i file a bug? where? A bit more info, for those curious: austin(a)sunwine:~$ dpkg -l | grep -e "libc\|binutils" ii binutils 2.22-1 GNU assembler, linker and binary utilities ii klibc-utils 1.5.25-1 small utilities built with klibc for early boot ii libc-bin 2.13-21 Embedded GNU C Library: Binaries ii libc-dev-bin 2.13-21 Embedded GNU C Library: Development binaries ii libc6 2.13-21 Embedded GNU C Library: Shared libraries ii libc6-dev 2.13-21 Embedded GNU C Library: Development Libraries and Header Files ii libc6-dev-sparc64 2.13-21 Embedded GNU C Library: 64bit Development Libraries for UltraSPARC ii libc6-sparc64 2.13-21 Embedded GNU C Library: 64bit Shared libraries for UltraSPARC ii libcairo-gobject2 1.10.2-6.1 The Cairo 2D vector graphics library (GObject library) ii libcairo2 1.10.2-6.1 The Cairo 2D vector graphics library ii libcap2 1:2.22-1 support for getting/setting POSIX.1e capabilities ii libcapi20-3 1:3.9.20060704+dfsg.2-12 ISDN utilities - CAPI support libraries ii libcapi20-dev 1:3.9.20060704+dfsg.2-12 ISDN utilities - CAPI development libraries ii libclass-isa-perl 0.36-3 report the search path for a class's ISA tree ii libcomerr2 1.42-1 common error description library ii libcroco3 0.6.2-2 Cascading Style Sheet (CSS) parsing and manipulation toolkit ii libcups2 1.5.0-13 Common UNIX Printing System(tm) - Core library ii libcups2-dev 1.5.0-13 Common UNIX Printing System(tm) - Development files CUPS library ii libcurl3-gnutls 7.22.0-3 Multi-protocol file transfer library (GnuTLS) ii libcwidget3 0.5.16-3.1 high-level terminal interface library for C++ (runtime files) ii libklibc 1.5.25-1 minimal libc subset for use with initramfs ii liblocale-gettext-perl 1.05-7+b1 module using libc functions for internationalization in Perl ii libpthread-stubs0 0.3-3 pthread stubs not provided by native libc ii libpthread-stubs0-dev 0.3-3 pthread stubs not provided by native libc, development files ii linux-libc-dev 3.1.1-1 Linux support headers for userspace development austin(a)sunwine:~$ uname -a Linux sunwine 3.1.0-1-sparc64 #1 Mon Nov 14 11:02:57 UTC 2011 sparc64 GNU/Linux if anyone would like ssh access, email me an ssh key. -- -Austin

Dec. 27, 2011

NVidia Texture Tools still useful?

by Scott Ritchie

I found this old bug report today, that I had forgotten about: https://bugs.launchpad.net/ubuntu/+bug/382512 Do we still have a use case for NVidia Texture Tools if I put these packages into the distro? Thanks, Scott Ritchie

Dec. 27, 2011

PLT Problems with Wine/Sparc

by André Hentschel

Hi, thanks to Austin i could work on our sparc port and it seems i have it it a workable state, the remaining problem is that somehow the plt entry to libwine is fixed up wrong. I know most people on the list don't know much about sparc, so wild guesses are all i want. --- snip --- readelf -r: 0002c988 00003315 R_SPARC_JMP_SLOT 00000000 wine_dbg_log + 0 objdump -D: 0002c988 <wine_dbg_log(a)plt>: 2c988: 03 00 00 78 sethi %hi(0x1e000), %g1 2c98c: 30 bf ff e1 b,a 2c910 <_PROCEDURE_LINKAGE_TABLE_> 2c990: 01 00 00 00 nop gdb: 0xf66957e0 <+288>: call 0xf66a8988 <wine_dbg_log(a)plt> (gdb) printf "%08x\n", (void*)*0xf66a8988 033dfa34 (gdb) printf "%08x\n", (void*)*0xf66a898C 81c06200 (gdb) printf "%08x\n", (void*)*0xf66a8990 01000000 (gdb) --- /snip (also available as http://pastebin.com/JFN2w6q2 if bad format) --- it crashes (SIGSEGV) at wine_dbg_log(a)plt (0xf66a8988) in imm32.dll.so (if i remove the TRACE from DllMain it continues to crash with other libwine functions in winex11) 033dfa34 seems like a wrongly fixed up opcode to me. What do you guess? Should i file a bug? where? -- Best Regards, André Hentschel

Dec. 26, 2011

Re: [PATCH 1/4] d3dx9/tests: Add effect parameter value GetMatrix() test.

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 http://testbot.winehq.org/JobDetails.pl?Key=16158 Your paranoid android. === WVISTAADM (32 bit effect) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

Dec. 26, 2011

Re: [PATCH 2/7] wined3d: Move srgb checks away from d3dfmt_get_conv.

by Diego Nieto Cid

Hi, I beleive this patch introduced some kind of regression. While testing Fallout the following message was printed to the screen: trace:d3d_surface:surface_allocate_surface (0x1a25f0) : Creating surface (target 0xde1) level 0, d3d format WINED3DFMT_P8_UINT, internal format 0x80e5, width 1024, height 512, gl format 0x1908, gl type=0x1401 err:d3d_surface:surface_allocate_surface >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexImage2D @ surface.c / 2571 Internal format 0x80e5 (GL_COLOR_INDEX8_EXT) is not valid for the format 0x1908 (GL_RGBA). Initially, the surface's format is 0x1900 (GL_COLOR_INDEX) which is compatible with the internal format above. On Thu, Apr 08, 2010 at 10:49:46PM +0200, Roderick Colenbrander wrote: > [...] > @@ -1553,7 +1581,7 @@ void surface_prepare_texture(IWineD3DSurfaceImpl *surface, const struct wined3d_ > > if (surface->Flags & alloc_flag) return; > > - d3dfmt_get_conv(surface, TRUE, TRUE, &desc, &convert, srgb); > + d3dfmt_get_conv(surface, TRUE, TRUE, &desc, &convert); > if(convert != NO_CONVERSION) surface->Flags |= SFLAG_CONVERTED; > else surface->Flags &= ~SFLAG_CONVERTED; > > @@ -1569,7 +1597,7 @@ void surface_prepare_texture(IWineD3DSurfaceImpl *surface, const struct wined3d_ > } > > surface_bind_and_dirtify(surface, srgb); > - surface_allocate_surface(surface, gl_info, &desc, width, height); > + surface_allocate_surface(surface, gl_info, &desc, srgb, width, height); > surface->Flags |= alloc_flag; > } > However before surface_allocate_surface is called d3dfmt_get_conv which translates the format to GL_RGBA. But the internal format remains in an incompatible value due to a reordering of the instructions which was introduced by the patch. On Thu, Apr 08, 2010 at 10:49:46PM +0200, Roderick Colenbrander wrote: > [...] > @@ -2126,18 +2153,6 @@ HRESULT d3dfmt_get_conv(IWineD3DSurfaceImpl *This, BOOL need_alpha_ck, BOOL use_ > *desc = *This->resource.format_desc; > *convert = NO_CONVERSION; > > - /* TODO: the caller should perform this check */ > - if(srgb_mode) { > - desc->glInternal = glDesc->glGammaInternal; > - } > - else if (This->resource.usage & WINED3DUSAGE_RENDERTARGET > - && surface_is_offscreen((IWineD3DSurface *) This)) > - { > - desc->glInternal = glDesc->rtInternal; > - } else { > - desc->glInternal = glDesc->glInternal; > - } > - > /* Ok, now look if we have to do any conversion */ > switch(This->resource.format_desc->format) > { Before applying the changes the processing of srgb_mode was done inside d3dfmt_get_conv. Depending on the value of this variable one of glGammaInternal, rtInternal or glInternal was used. But those values were overriden because the conversion was applied afterwards. On Thu, Apr 08, 2010 at 10:49:46PM +0200, Roderick Colenbrander wrote: > [...] > @@ -783,11 +797,25 @@ static void surface_upload_data(IWineD3DSurfaceImpl *This, const struct wined3d_ > * the correct texture. */ > /* Context activation is done by the caller. */ > static void surface_allocate_surface(IWineD3DSurfaceImpl *This, const struct wined3d_gl_info *gl_info, > - const struct wined3d_format_desc *format_desc, GLsizei width, GLsizei height) > + const struct wined3d_format_desc *format_desc, BOOL srgb, GLsizei width, GLsizei height) > { > BOOL enable_client_storage = FALSE; > const BYTE *mem = NULL; > - GLenum internal = format_desc->glInternal; > + GLenum internal; > + > + if (srgb) > + { > + internal = format_desc->glGammaInternal; > + } > + else if (This->resource.usage & WINED3DUSAGE_RENDERTARGET > + && surface_is_offscreen((IWineD3DSurface *)This)) > + { > + internal = format_desc->rtInternal; > + } > + else > + { > + internal = format_desc->glInternal; > + } > > if (format_desc->heightscale != 1.0f && format_desc->heightscale != 0.0f) height *= format_desc->heightscale; > After the change was applied the result of the conversion done inside d3dfmt_get_conv only takes effect in the else branch of srgb processing. The following code is the conversion involved in this particular test case. format->glFormat = GL_RGBA; format->glInternal = GL_RGBA; format->glType = GL_UNSIGNED_BYTE; format->conv_byte_count = 4; It's located in d3dfmt_get_conv under the WINED3DFMT_P8_UINT case. For some reason only glInternal is updated by the conversion. In any case it didn't matter before the patch as none of the internal values were actually used in case a conversion was applied. Should the three internal values be updated by the conversion now that any of them could be used? Even if it would work I'm not sure how correct would be to do that. Could some wined3d developer review the patch with all this in mind? Thanks!

Dec. 26, 2011