March 2015 - Wine-devel - list.winehq.org

Re: [PATCH 5/5] wined3d: Don't use the builtin FFP uniforms for texture transformation matrices.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 20 March 2015 at 13:50, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + get_texture_matrix(context, state, tex, &mat); > + GL_EXTCALL(glUniformMatrix4fv(prog->vs.texture_matrix_location[tex], 1, FALSE, (GLfloat *)&mat)); Like 110106. > + for (i = 0; i < MAX_TEXTURES; ++i) > + { > + char name[22]; > + > + sprintf(name, "ffp_texture_matrix[%u]", i); I'd feel slightly happier if this kind of thing used snprintf(), but I also think it's about time we start using something along the lines of shader_addline() for these.

1 0

Re: [PATCH 3/5] wined3d: Don't use the builtin FFP uniform for the projection matrix.
by Henri Verbeet 23 Mar '15

23 Mar '15

On 20 March 2015 at 13:50, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (update_mask & WINED3D_SHADER_CONST_FFP_PROJ) > + { > + struct wined3d_matrix projection; > + > + get_projection_matrix(context, state, &projection); > + GL_EXTCALL(glUniformMatrix4fv(prog->vs.projection_matrix_location, 1, FALSE, (GLfloat *)&projection)); I'd prefer that as "&projection._11", avoiding the cast.

1 0

Re: user32: Fix padding in user_thread_info structure.
by Alexandre Julliard 23 Mar '15

23 Mar '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Based on the comment above only TEB->Win32ClientInfo should be used to store the struct user_thread_info. > The padding got out of sync in cb3b7237925a24ba4c5696dd079fdc5d99a48577 where the 64-bit situation was ignored. > The pshpack4 is required because the struct has a size of 31 ULONGs, and gcc will otherwise align the whole > struct up to 8 bytes on 64-bit. I've confirmed manually with C_ASSERTs that the offsets/sizes are right and > that it matches what we expect. I don't see any need to change the packing, there's still enough room. I'd suggest to simply replace the padding with an assert on the structure size. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32: Use correct font for themed headers. (try 2)
by Nikolay Sivov 23 Mar '15

23 Mar '15

On 23.03.2015 10:51, Mark Harmstone wrote: Hi, Mark. Thanks for looking into this. > + > + if (theme) { > + LOGFONTW lf; > + HRESULT hr = GetThemeFont(theme, hdc, HP_HEADERITEM, state, TMT_FONT, &lf); > + if (SUCCEEDED(hr)) { > + font = CreateFontIndirectW(&lf); > + if (!font) > + TRACE("Failed to create font\n"); > + else { > + TRACE("font = %s\n", debugstr_w(lf.lfFaceName)); > + oldfont = SelectObject(hdc, font); > + created_font = TRUE; > + } > + } else { > + font = (HFONT)SendMessageW(infoPtr->hwndSelf, WM_GETFONT, 0, 0); > + oldfont = SelectObject(hdc, font); > + } > + } > + > DrawTextW (hdc, phdi->pszText, -1, > &textRect, DT_LEFT|DT_VCENTER|DT_SINGLELINE|DT_CALCRECT); > cw = textRect.right - textRect.left + 2 * infoPtr->iMargin; > + > + if (font) SelectObject(hdc, oldfont); > + if (created_font) DeleteObject(font); This seems to essentially duplicate GetThemeTextExtent(). Any reason why you can't use it instead?

1 0

Adding HID joystick support to FreeBSD
by Bruno Jesus 23 Mar '15

23 Mar '15

Hi, all. In order to add HID joystick support to FreeBSD I need to do some changes I never did before so I could use some help. I tried to understand the changes made by Ken in order to add the winmm OSX driver but I don't get it =) In simple words I need to ensure that usbhid.h and dev/usb/usbhid.h exist and only if they exist compile the winejoystick driver. I believe it's a change in configure.ac but I tried adding these .h files to the long list of other .h files and it didn't work. Also I guess a similar change is needed like Ken did to enable the driver building: -test "$ac_cv_header_linux_joystick_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no} +test "$ac_cv_header_linux_joystick_h" = "yes" -o "$ac_cv_header_IOKit_hid_IOHIDLib_h" = "yes" || enable_winejoystick_drv=${enable_winejoystick_drv:-no} Can anyone help? Best wishes and thanks in advance, Bruno

6 7

Re: comctl32/listview: Update view on style change only if LVS_TYPEMASK styles have changed
by Marvin 23 Mar '15

23 Mar '15

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=12359 Your paranoid android. === w7u (32 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5121: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5126: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

WIP: FreeBSD 10 usbhid joystick support
by Bruno Jesus 23 Mar '15

23 Mar '15

For those wondering (probably a few, lol) this is the WIP patch that is actually working for the standard HID gamepad I have. I also tried testing in a PS2 controller attached in a USB converter but FreeBSD does not recognize it. The configure part is still missing and it required "-lusbhid" to compile and I didn't find the correct place to add that so I'm currently compiling manually. I labeled it as FreeBSD 10 only because it was the only one I tried, probably may require changes to support other BSD systems. This task is proving to be harder than I expected due to my lack of knowledge in the area and any help testing is appreciated specially with different gamepads/joysticks (for example a joystick with a HAT). The problem with configure.ac is that both usbhid.h and dev/usb/usbhid.h must be included and that would require a compound "-o" switch to ensure that both must be present in order to make the driver. The last problem is where to put that -lusbhid is required when compiling the file. And of course testing in the configure script if usbhid lib is present. Best regards, Bruno

1 0

Re: [PATCH 3/3] scrrun: Support BYREF types for integer keys
by Marvin 22 Mar '15

22 Mar '15

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=12362 Your paranoid android. === wvistau64 (64 bit dictionary) === dictionary.c:542: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:542: Test failed: got hash 0x000001f4

1 0

Re: [PATCH 2/3] scrrun: Added support for VT_DATE keys, and BYREF float key types
by Marvin 22 Mar '15

22 Mar '15

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=12361 Your paranoid android. === wvistau64 (64 bit dictionary) === dictionary.c:508: Test failed: got hash 0x000001f4 === w2008s64 (64 bit dictionary) === dictionary.c:508: Test failed: got hash 0x000001f4

1 0

Re: msvcrt: Fix bugs in math.c
by Piotr Caban 22 Mar '15

22 Mar '15

Hi, On 03/22/15 12:28, 陈正 wrote: > - Fixed the problem of atan(INF)/tanh(INF)/exp(INF) causing errno EDOM > - Fixed the error of _copysign(1., -0.) returning 1 Please don't send unrelated changes in one patch, please split it into 2 patches. The changes that remove errno setting from atan, tanh and exp looks good for me. > float CDECL MSVCRT__copysignf( float num, float sign ) > { > - /* FIXME: Behaviour for Nan/Inf? */ > - if (sign < 0.0) > - return num < 0.0 ? num : -num; > - return num < 0.0 ? -num : num; > + /* FIXME: Behaviour for signbit(NAN) is different in Linux and > + * Windows, where Windows gives a zero for -NAN > + */ > + if (signbit(sign)) > + return signbit(num) ? num : -num; > + return signbit(num) ? -num : num; > } Why don't you add an isnan() check? Is there any reason for returning "signbit(num) ? -num : num" instead of returning num? It would be nice to also change signbit definition on systems that doesn't support it, so it at least works for normal numbers. Thanks, Piotr

3 6