November 2015 - Wine-Devel - list.winehq.org

Re: [v3 resend2] d3d9: call wined3d_device_copy_sub_resource_region instead of wined3d_device_update_surface in d3d9_device_UpdateSurface

by Riccardo Bortolato

Thanks, I sent an updated couple of patches. Unfortunately I forgot the v4 tag, sorry for that. Ciao, Riccardo 2015-11-03 13:14 GMT+01:00 Stefan Dösinger <stefandoesinger(a)gmail.com>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > I spotted a few style issues. Not sure if that's what Henri didn't > like about it, or if he disagrees with the concept of the patch. > > Am 2015-11-03 um 08:34 schrieb Riccardo Bortolato: >> + if (!(sub_resource = wined3d_texture_get_sub_resource(src->wined3d_texture, src->sub_resource_idx))) >> + { >> + WARN("no subresource found for texture %p sub_resource_idx %u\n", src->wined3d_texture, src->sub_resource_idx); > We usually have a period at the end of wined3d trace messages. > >> + WARN("source %p must be SYSTEMMEM and dest %p must be DEFAULT, returning WINED3DERR_INVALIDCALL\n", >> + src_surface, dst_surface); >> + wined3d_mutex_unlock(); >> + return D3DERR_INVALIDCALL; > The trace message mentions the wrong return value (WINED3DERR... vs > D3DERR...). > >> + hr = wined3d_device_copy_sub_resource_region(device->wined3d_device, >> + wined3d_texture_get_resource(dst->wined3d_texture), dst->sub_resource_idx, dst_point ? dst_point->x : 0, >> + dst_point ? dst_point->y : 0, 0, wined3d_texture_get_resource(src->wined3d_texture), >> + src->sub_resource_idx, &src_box); > Indentation (8 spaces for the line continuations). > > Stefan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWOKUmAAoJEN0/YqbEcdMwCaIP/A/V33gPqKBJtBJAXi8UnsEG > dENusnecbrxauf6Sc6x5g7cYriBUEph5ndYa96y+lv8qKuOg9jVLeoUkfBHqpE8f > V77p3cCnAJJ2XzbFJkqu8jY5GKvaAmoizezOyPRi/lgXa2xydH5yzW5NFu27Rbq8 > KeG3kuBIBDzkJ1poSUvYWvSqUTGOeaUEYZBkDttqPegHvjPpYJg6MAzpr33c/F5P > s5ttSwhRdPFQJU3iktZKElhuUX2SBZnBwcueR4xAN+/4bRCIAhy2tnPXbQgC8Tih > dcQzVWCoQ+qK3nmYjDUrwvvWdEF78D+BOQzVtOOn4kHZwE1XQ7M1paV8en0uV0VS > D8Jdx4shCQGkxZncBsfysbEPkqgApukCFJp34JfXWFxlpVbiK6m2Y3DzsdyhGxek > Ky30AIY7FadUit5KWehcqDUj9Z8HOFdgcCe0KWqeFpeQn4G6t9gfJiiKYRV3m6TD > OxwLT+HcD4lozPARMTq6IT7pV3hOG0xdKNuTKfgji9+8RWRNz5nGa/Ml4WzS49lV > YHV06Nnb3ayw1CYTBoK2jwp5hBzAybdghSW7sKNJ6gLy3JFsZOKpKnr2yVxV1WD2 > g8E5+tqwPDxgiriDOZrM5tPTc8+QLSaIm+Q59TKE3ScSvWVZArERVMtAk8/vd7BA > nAXvxDoQsVBSa7z+zwRC > =+ADb > -----END PGP SIGNATURE-----

Nov. 3, 2015

Re: [PATCH 1/8] Revert "wined3d: Track if a context's private hdc has had its pixel format set, so we don't need to check it."

by Alexandre Julliard

Henri Verbeet <hverbeet(a)gmail.com> writes: > On 2 November 2015 at 22:46, Ken Thomases <ken(a)codeweavers.com> wrote: >> As to why a year and a half isn't enough time to fix it: when >> velocity is 0, distance traveled is going to be 0 regardless of >> time. I'm no longer working on the proper fix. Let's chalk it up >> to emotional immaturity on my part. If that makes you reluctant to >> have my work in wined3d, then you have a sticky dilemma to >> resolve. ;) >> > I have my own theory, but regardless of who or what you blame it on, > it does indeed make me more hesitant to sign off on your changes, > nothing sticky about that. It doesn't matter who's to blame, the fact is that we won't get the proper fix for 1.8, so what I'd like to hear is your opinion on whether it's better to revert the change or ship 1.8 with that regression. -- Alexandre Julliard julliard(a)winehq.org

Nov. 3, 2015

Re: [PATCH 1/8] Revert "wined3d: Track if a context's private hdc has had its pixel format set, so we don't need to check it."

by Henri Verbeet

On 2 November 2015 at 22:46, Ken Thomases <ken(a)codeweavers.com> wrote: > As to why a year and a half isn't enough time to fix it: when velocity is 0, distance traveled is going to be 0 regardless of time. I'm no longer working on the proper fix. Let's chalk it up to emotional immaturity on my part. If that makes you reluctant to have my work in wined3d, then you have a sticky dilemma to resolve. ;) > I have my own theory, but regardless of who or what you blame it on, it does indeed make me more hesitant to sign off on your changes, nothing sticky about that.

Nov. 3, 2015

Re: [v3 resend2] d3d9: call wined3d_device_copy_sub_resource_region instead of wined3d_device_update_surface in d3d9_device_UpdateSurface

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I spotted a few style issues. Not sure if that's what Henri didn't like about it, or if he disagrees with the concept of the patch. Am 2015-11-03 um 08:34 schrieb Riccardo Bortolato: > + if (!(sub_resource = wined3d_texture_get_sub_resource(src->wined3d_texture, src->sub_resource_idx))) > + { > + WARN("no subresource found for texture %p sub_resource_idx %u\n", src->wined3d_texture, src->sub_resource_idx); We usually have a period at the end of wined3d trace messages. > + WARN("source %p must be SYSTEMMEM and dest %p must be DEFAULT, returning WINED3DERR_INVALIDCALL\n", > + src_surface, dst_surface); > + wined3d_mutex_unlock(); > + return D3DERR_INVALIDCALL; The trace message mentions the wrong return value (WINED3DERR... vs D3DERR...). > + hr = wined3d_device_copy_sub_resource_region(device->wined3d_device, > + wined3d_texture_get_resource(dst->wined3d_texture), dst->sub_resource_idx, dst_point ? dst_point->x : 0, > + dst_point ? dst_point->y : 0, 0, wined3d_texture_get_resource(src->wined3d_texture), > + src->sub_resource_idx, &src_box); Indentation (8 spaces for the line continuations). Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWOKUmAAoJEN0/YqbEcdMwCaIP/A/V33gPqKBJtBJAXi8UnsEG dENusnecbrxauf6Sc6x5g7cYriBUEph5ndYa96y+lv8qKuOg9jVLeoUkfBHqpE8f V77p3cCnAJJ2XzbFJkqu8jY5GKvaAmoizezOyPRi/lgXa2xydH5yzW5NFu27Rbq8 KeG3kuBIBDzkJ1poSUvYWvSqUTGOeaUEYZBkDttqPegHvjPpYJg6MAzpr33c/F5P s5ttSwhRdPFQJU3iktZKElhuUX2SBZnBwcueR4xAN+/4bRCIAhy2tnPXbQgC8Tih dcQzVWCoQ+qK3nmYjDUrwvvWdEF78D+BOQzVtOOn4kHZwE1XQ7M1paV8en0uV0VS D8Jdx4shCQGkxZncBsfysbEPkqgApukCFJp34JfXWFxlpVbiK6m2Y3DzsdyhGxek Ky30AIY7FadUit5KWehcqDUj9Z8HOFdgcCe0KWqeFpeQn4G6t9gfJiiKYRV3m6TD OxwLT+HcD4lozPARMTq6IT7pV3hOG0xdKNuTKfgji9+8RWRNz5nGa/Ml4WzS49lV YHV06Nnb3ayw1CYTBoK2jwp5hBzAybdghSW7sKNJ6gLy3JFsZOKpKnr2yVxV1WD2 g8E5+tqwPDxgiriDOZrM5tPTc8+QLSaIm+Q59TKE3ScSvWVZArERVMtAk8/vd7BA nAXvxDoQsVBSa7z+zwRC =+ADb -----END PGP SIGNATURE-----

Nov. 3, 2015

Re: [PATCH 2/5] ddraw: check if surface is a mipmap sublevel through caps in ddraw_surface7_GetPriority

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2015-11-03 um 11:45 schrieb Riccardo Bortolato: > - else if (!(surface->surface_desc.ddsCaps.dwCaps2 & managed) || !surface->wined3d_texture) > + else if (!(surface->surface_desc.ddsCaps.dwCaps2 & managed) || (surface->surface_desc.ddsCaps.dwCaps2 & DDSCAPS2_MIPMAPSUBLEVEL)) This will show different behavior on level 0 Y, Z and negative X cube map surfaces. (Positive X is the actual ddraw root surface). However, I vagely remember that native ddraw also misbehaved here, so the new behior is probably correct. I'll check with my SetColorKey tests and report back. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWOKFcAAoJEN0/YqbEcdMw+58P/2gMcrKJWf0CAQXZ4rATJiwt 5MzyMISpifgcKjmV/YdYz/cJG98QcOCUgOqHCHzBi2iXfDZth1y6PX9qMdR3wT5q OzT++ZiJa+JVYUjn5eNbpV7VUXxghqCS6yyD+je9wkgGAEWIgJaN5txiyXx91qAQ 5Pxe0dUHSJDD/sb2e3UTOzQoQsuE+vQWbho82Los5IJTs2Bl3fOqmwuDIpGdteYM TRsMkWLY7UUeb4XrSjTmDw37eHsWXoEAH2RC/HXTbbY+NDzW5a948Uk0YgHtEDSP sUbiYVJaIw2eM67dKC1mF+g9H3hsNtKw8EhqyUUEoFjl4bq9O8w4K9QaHPEXULEQ dIuUq/tOWGimPIGjMYQqS+aWB28L4H0SER0zC8uX1x/vO8W3+lmLoXgKp2p85K3g AJZmxO6lEZFEHvhDuIUlfWoSOOuc+rlHSDsgII7Qhy3V2wPrI01NNyUTfeLx3z2r Q35tSsi/j4me9tWgcNth0TdYstE7/aDej8bWv7MXj2xo+p3v6y6ppGnadjzHqNsu skKcgQpQIHt+2F4fPX3/xwj/CpvK7i8UwTC5/Zp+nGI3qxdCD1lNNTBQJA8Ajl9Y 8yWOpvR6tjhMc898qBOKp4opXbqW8x2hyIDGF/binGlHlKa2vOfsCl5JY0y4TzpL eDENyDHAisigjU/8qZYJ =ejR9 -----END PGP SIGNATURE-----

Nov. 3, 2015

Broken PulseAudio configure check

by Francois Gouget

The PulseAudio configure check is broken: WINE_PACKAGE_FLAGS(PULSE,[libpulse],,,, [AC_CHECK_HEADERS(pulse/pulseaudio.h, [AC_CHECK_LIB(pulse,pa_stream_is_corked,[:],,[$PULSE_LIBS])])]) [...] test -n "$PULSE_LIBS" || enable_winepulse_drv=${enable_winepulse_drv:-no} WINE_PACKAGE_FLAGS() sets PULSE_LIBS but PULSE_LIBS is not unset even if AC_CHECK_LIB() fails. As a result compilation of winepulse.drv is enabled even if libpulse.so is missing. I don't have the 32-bit libpulse.so library so this resulted in a compilation error here: ../../tools/winegcc/winegcc -o winepulse.drv.so -B../../tools/winebuild -m32 -fasynchronous-unwind-tables -shared winepulse.drv.spec \ mmdevdrv.o -ldxguid -luuid -lwinmm -luser32 -ladvapi32 -lole32 -lwine \ ../../libs/port/libwine_port.a -lpulse -lpthread /usr/bin/ld: cannot find -lpulse collect2: error: ld returned 1 exit status winegcc: gcc failed Makefile:185: recipe for target 'winepulse.drv.so' failed I also find it strange that all these audio modules are enabled/disabled at the end of the configure.ac file instead of where support is checked. Also the 'Check for any sound system' should probably not look into the internals of audio systems (i.e. check for PULSE_LIBS) and instead only rely on the enable_xxx_drv variables which should have been set by then. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Nov. 3, 2015

Re: [2/2] msi: Make sure to reset the 'in_quotes' state in all cases.

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://testbot.winehq.org/JobDetails.pl?Key=17929 Your paranoid android. === w7u (32 bit install) === The test timed out

Nov. 3, 2015

Re: [PATCH v2 4/7] ucrtbase: Implement the new printf corner case behaviour

by Piotr Caban

On 11/03/15 10:40, Martin Storsjö wrote: > On Tue, 3 Nov 2015, Piotr Caban wrote: >> On 11/02/15 22:26, Martin Storsjo wrote: >>> - if (options & ~UCRTBASE_PRINTF_TERMINATION_MASK) >>> - FIXME("options %s not handled\n", >>> wine_dbgstr_longlong(options)); >> Shouldn't this be changed to: >> if(options & ~UCRTBASE_PRINTF_MASK) >> FIXME("...); >> instead of being removed? > > Perhaps, although these are all the flags that are currently defined, so > as far as I can see, there's nothing left to warn about (unless someone > calls this internal function deliberately with weird/undefined flags). > (The mask when caling pf_printf is only to make sure that we don't > accidentally alias the flags of our own.) > > Should we keep a warning in case a future version adds more flags? Yes, please add a warning. Thanks, Piotr

Nov. 3, 2015

Re: [PATCH v2 5/7] msvcrt: Interpret 'I' as size_t size specifier for integer conversions

by Martin Storsjö

On Tue, 3 Nov 2015, Piotr Caban wrote: > On 11/02/15 22:26, Martin Storsjo wrote: >> + format = "%Ix %d"; >> + r = sprintf(buffer,format,0x123456,1); >> + ok(!strcmp(buffer,"123456 1"),"Pointer formatted incorrectly\n"); >> + ok( r==8, "return count wrong\n"); > Please change the test failure message (I would prefer something like > ok(!strcmp(...), "buffer = %s\n", buffer)). Oh, right - too much copypaste here. Will change. // Martin

Nov. 3, 2015

Re: [PATCH v2 4/7] ucrtbase: Implement the new printf corner case behaviour

by Martin Storsjö

On Tue, 3 Nov 2015, Piotr Caban wrote: > On 11/02/15 22:26, Martin Storsjo wrote: >> + test_legacy_wide(); >> + test_legacy_msvcrt(); >> + test_legacy_three_digit_exp(); > I also think it would be nicer if this tests are called e.g. > test_printf_legacy_wide. Sure, I can change that. // Martin

Nov. 3, 2015