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

My ideas for GSoC 2015
by HuddenSin Yuan March 24, 2015

March 24, 2015

Hello, everyone. I’m Yuan Chen, a college student from China. I will have plenty of time to join GSoC 2015 and I have send two patches about mshtml.dll before and now I study gdi32 module and the Computer Graphics. Here is my idea for GSoC 2015. Improve the basic drawing functions and add GM_ADVANCED mode support ===================================== I found several bugs which show many basic curve and fonts drawing functions don’t support the GM_ADVANCED mode[1][2][3]. And the curve will become odd under this mode. I have written a test case to show these problems[9]. 1.add GM_ADVANCED mode support When I find that wine use polygon to fit the rect in GM_ADVANCED mode(polygon function is not good enough according to [4]). So I think we can use bezier spline or B spline to fit the curve like ellipse or arc in GM_ADVANCED mode[5][6]. There is also a paper about fonts capturing[7]. So the driver functions of curve and fonts like draw_arc, draw_glyph will be improved and added the GM_ADVANCED support. 2.improve the basic drawing functions In order to fix those above, we need to improve and add some basic helper functions in dlls/gdi32/dibdrv/graphics.c. get_arc_points will be improved and some helper functions will be added which help to calculate the coordinate of points of the curves in GM_ADVANCED mode.This part will take about three weeks. The bezier function need to be improved to n points instead of 3n+1 points according to Bresenham’s Algorithm[8]. This function will take less than one week. And I also try to improve the ellipse_first_quadrant functions using the Bresenham’s Algorithm.[10] Perhaps my idea is not mature enough, I will be appreciate it very much if anyone give me some advice! Thanks! [1]https://bugs.winehq.org/show_bug.cgi?id=33190 [2]https://bugs.winehq.org/show_bug.cgi?id=35333 [3]https://bugs.winehq.org/show_bug.cgi?id=35169 [4]https://bugs.winehq.org/show_bug.cgi?id=36891 [5]http://sarahfrisken.com/efficientCurveFitting.pdf [6]http://www.dtic.mil/dtic/tr/fulltext/u2/a350611.pdf [7]http://www.cs.uml.edu/~wanthony/91.427_f2008/cglr1/reference.pdf [8]http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm [9]see the attachment “testforadvanced.txt" [10]see the attachment "0001-gdi32-Improve-the-algorithm-of-ellipse_first_quadrant.txt" ---------------------------------------- Best Regards , Yuan Chen

1 0

Re: Google Summer of Code 2015
by Matteo Bruni March 24, 2015

March 24, 2015

2015-03-24 11:38 GMT+01:00 Лёша Долгавин <dolgavin.alexey(a)gmail.com>: > Hello Matteo, > Hi Alexey, > I'm the last year student of Moscow institute. > I found you as possible mentors in project ideas. And I want to implement > missing APIs in D3DX (math and/or mesh functions). Cool! > So, I have a question: do I need to do some task or you will choose students > for this project from their proposal? Yes, you will have to write a proposal in Melange (i.e. the GSoC website) and have submitted at least one patch to wine-patches to be considered for acceptance. I suggest you to download Wine's source code, build it and give a look at the D3DX code (both the implementation of the existing functions and the tests, that's in dlls/d3dx9_36/ and the tests/ subdirectory within). Then it might be a good idea to try to run some game using d3dx on Wine, you can e.g. search bugs.winehq.org to find some. You can then try to implement one of the missing functions and see how it's like. Eventually you'll have to choose a set of the missing APIs you want to work on during your GSoC and write a suitable proposal. You'll get feedback on it and you'll be able to update it so don't worry on getting it exactly right on the first try. If you have further questions don't hesitate to ask. It's much better if you also include wine-devel(a)winehq.org in cc the next times, others might be able to reply faster / better than me. There is also the #winehackers IRC channel on freenode available. > I have strong knowledge in math and have experience in commercial software > developing. That's good. Make sure to write that in your proposal :)

1 0

Re: [PATCH] findstr: Added test for findstr.
by Stefan Dösinger March 24, 2015

March 24, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Thanks for your patch! I have a few comments: Am 2015-03-23 um 04:14 schrieb Kaipeng Zeng: > index 5f5e9d5..f3056c7 100755 > --- a/configure > +++ b/configure You don't have to include the change to configure in your patch, Alexandre will update it himself. > diff --git a/configure.ac b/configure.ac > index d23227a..822affe 100644 > ... > WINE_CONFIG_PROGRAM(findstr,,[install]) > +WINE_CONFIG_TEST(programs/findstr/tests) > WINE_CONFIG_PROGRAM(hh,,[install]) I don't think we have any precedent for having tests without having at least a stub implementation. Personally I don't see anything wrong with having just a test for now. Can you make sure that the test is properly built and included in winetest.exe? Do you intend to implement the program itself? > +static DWORD runcmd(const char* cmd, char *output) > ... > + CloseHandle(hRead); > + return TRUE; > +} I think it would be a good idea to return the return value of findstr here instead of always returning true when CreateProcess succeeds. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVD/UWAAoJEN0/YqbEcdMwh8EP/37ev7ZrJHzmNy5AJfbuzY/s 3wxUIKIo5hwrjJeiwpdFCWAtDQGMo3Hz8weLLyAaCpT4OVrzz/DvbWFLxX3zCl2Z 9EhetkZkyfiPBUF1T+s/WdTse51J9qeP8mFI7NgQdwuwUOXyp2Ba7Kq8DVBM6sNW MtWsKdItE298jTzL21oQ59w9ar6YrFwRTcVcvLQ3JPmLKSfJ5MR2qT1SxIO6nVC9 Omqc89R9Ba3jSFv+5c3l0Zn6zgnf/U5YBPmsOMYb9DWLNvD0ZgiBh5NZkLxYcV16 NLHQWxJy3mO11RNyjSn1Ank26rR1MiM4kVT7tK3WvneM1IZW7Z/RugGaymtTgfBq vIIMKidz2hPrIwmuy4AYSEb9ScJIT+b2DCbwgJEWgmxTPl3mymW5ltXLx8yzcmhV y7GNYGVKuaH6CZeyHLimeLGA845qCzXW15vWxaB6PGw+lVlqpq4mWJnWcB2NOsC+ Auw4vubTf8KTs2UHyQily9AaahthU5IkZA6sPBDpTlZCNlGpRXa+gW88WpKjd5wV 5y9otOU49Fhp704uZAiVcX9ag5cTFaseu0AsTN/TKmYToA50bzAmJr+2/+nJEQIf lcahIWPeyYw1u7rF3cOEZfkN7FIx/ab1gv1hETLvyoKz/nnYb9NPztnnK3HDFNRP XJl+R82YChN/YV946HfO =6sQQ -----END PGP SIGNATURE-----

3 6

Re: msvcrt: fix _copysign(1., -0.) error
by Piotr Caban March 24, 2015

March 24, 2015

On 03/22/15 14:51, Kevin Chan wrote: > 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; It doesn't make sense to add this comment and remove it in next patch. I would also prefer if signbit fallback implementation is changed in this patch. +/* FIXME: Doesnot work with +-NAN and -0. */ There's a typo in this comment. Also it works for NAN with sign bit set to 0. +#define signbit(x) ((x) < 0 ? 1 : 0) This can be simplified to: #define signbit(x) ((x)<0)

2 1

Re: msvcrt: Add errno EDOM setting for atan(NAN)/exp(NAN)/tanh(NAN)
by Piotr Caban March 24, 2015

March 24, 2015

Hi, On 24/03/15 09:01, Zheng Chen wrote: > --- > dlls/msvcrt/math.c | 3 +++ > 1 file changed, 3 insertions(+) The patch needs to be generated on top of clean wine. This will not apply without applying all your earlier patches. Please send a patch that contains all the changes to atan, exp and tanh functions. Thanks, Piotr

2 1

Re: msvcrt: remove errno EDOM from atan, exp and tanh
by Piotr Caban March 24, 2015

March 24, 2015

Hi, On 03/22/15 14:50, Kevin Chan wrote: > double CDECL MSVCRT_atan( double x ) > { > - if (!isfinite(x)) *MSVCRT__errno() = MSVCRT_EDOM; > return atan(x); > } I've done a little more testing. The function is not setting errno in INF and -INF case. It does set errno to EDOM when argument is NAN. Thanks, Piotr

2 1

Re: [PATCH] comctl32: Use correct font for themed headers. (try 4)
by Nikolay Sivov March 24, 2015

March 24, 2015

Looks good, thanks.

1 0

submitting report
by Shubham kumar March 24, 2015

March 24, 2015

I ran winetest.exe on my pc and it generated a output file resDD89.tmp. How can i view this report? On which website i have to upload this file to generate the log? Thank you

2 1

Re: [PATCH] comctl32: Use correct font for themed headers. (try 3)
by Nikolay Sivov March 23, 2015

March 23, 2015

On 03/23/2015 10:44 PM, Mark Harmstone wrote: Hey, looks much better, thanks. One minor thing left, and I'm sorry that I missed it last time: > + if (theme) { > + DrawThemeText(theme, hdc, HP_HEADERITEM, state, phdi->pszText, > + lstrlenW(phdi->pszText), DT_LEFT|DT_END_ELLIPSIS|DT_VCENTER|DT_SINGLELINE, > + 0, &r); > + } else { > + Will it work as docs claim if you simply pass -1 as a text length? Otherwise looks good to me.

1 0

Re: [PATCH 1/5] wined3d: Only set TEXTURE_COMPARE_FUNC when ARB_depth_texture is supported.
by Henri Verbeet March 23, 2015

March 23, 2015

On 23 March 2015 at 18:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - if (desc->compare) > - GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)); > - GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_FUNC, > - wined3d_gl_compare_func(desc->comparison_func))); > + if (gl_info->supported[ARB_DEPTH_TEXTURE]) > + { > + if (desc->compare) > + GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_MODE, GL_COMPARE_R_TO_TEXTURE)); > + GL_EXTCALL(glSamplerParameteri(sampler->name, GL_TEXTURE_COMPARE_FUNC, > + wined3d_gl_compare_func(desc->comparison_func))); > + } Does the driver generate GL errors without this? The way I read the ARB_sampler_objects spec that would a driver bug. (Specifically, it states that TEXTURE_COMPARE_MODE/TEXTURE_COMPARE_FUNC are accepted by SamplerParameter(), without qualifying that with a dependency on ARB_depth_texture. I guess a driver that doesn't support depth textures can essentially just ignore the texture compare mode/function, since it would never encounter a texture it would apply to.)

2 1

Re: d3dx9_36: Align texture dimensions to block size for compressed textures in D3DXCheckTextureRequirements.
by Stefan Dösinger March 23, 2015

March 23, 2015

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/23/15 15:50, Sebastian Lackner wrote: > + format = D3DFMT_DXT5; > + width = 5; height = 5; > ... > + ok(mipmaps == 1, "Returned mipmaps %d, expected %d\n", mipmaps, 1); I'm curious, why does it report 1 mipmap level? Maybe because width / 2 is smaller than the block size, even though the block-size aligned width would allow a second level. What does d3dx9 return when you have width = height = 10 for example? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVEDcbAAoJEN0/YqbEcdMwVyAQAIusV1Z29v1LQQGKJtBdZk9C g+KRkCEcHalFEjwSHL4689U+GtQVigN1OSIJAtsSvrHBpslwtwsA+q7Crgamuk2X zQ+sxYOHE3QIoD2yy/uQElKxfLZWzBQjeUjZGMdYPLv4Bc2NRp4tMexPMKsHVeDx WubraUfiG40uWwcuFTfODuwuybZjWBUk89PIy865PS++/24wO12WB5vP+dK4XEB4 Mrv4Vzv+8f2zVO+tIWtXgr439f4skF4o5peOwe8qN7KxNSkqKduIWf/5dLfgZhgt lqUrziNNcWaVy5poM/cVeo7P4KKMJLjlT9ehItGee1S7gUUiatyGAKyttN5zauiV SRqJSq8sKWSGCDb/779aTonPVkLnHZVWHblJAihrCBuyE3tZVJpgg9xE3rWMyM8d IstQxbGEgDgQmrXxkeox6M3FnkBp3NL8ALzL5NHHoUxPJMg1yz5cGWuiqdBGYPM1 LmqynuRlXERLBMen/Rn69f/KFdGgqitPhzPupZ3nIGAi1Cku4Vjwd92nUS9ruZS9 uTT0t+wAjCvfKMBCfj0nnmQ4y7W9bmCxDVZs/Md83Ed4G49crTo7XTtrZnWDH4GU gFoGbn+BjcU7uankhoC5tq+XatHr6oRkWIrO5jJg2Oyk9Wns5cyanuvfGdwYrQT8 T+IYcghTfBRrDRNKHrqg =YJRY -----END PGP SIGNATURE-----

2 1

Re: d3dx9_36: Align texture dimensions to block size for compressed textures in D3DXCheckTextureRequirements.
by Henri Verbeet March 23, 2015

March 23, 2015

On 23 March 2015 at 15:50, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > + if (w % fmt->block_width) > + w += fmt->block_width - w % fmt->block_width; > + if (h % fmt->block_height) > + h += fmt->block_height - h % fmt->block_height; Could you please just use the conventional way to align something?

1 0

Counting bits set in a 32 bit value
by Bruno Jesus March 23, 2015

March 23, 2015

Hi all, after some manual testing I noticed that the joystick structure member dwButtonNumber is not the last button pressed but instead the count of pressed buttons. There is a bit field of buttons set in the structure member dwButton, to fix the number in dwButtonNumber I guess the easiest way is to count the bits set. I think that keeping a counter with ++/-- operations could lead to out of sync situations if the joystick is not polled fast enough. Is there any precedent need for this in wine? Is there an accepted solution for it? Internet searching shows different ways like bit counting with shift, using cpu instructions or internal compiler functions. Best wishes, Bruno

2 1

Re: dsound: Fix angle to sound source calculation.
by Andrew Eikum March 23, 2015

March 23, 2015

This seems sane to me, but I never had a good grasp on this to begin with. Does it look OK to you, Mark? Andrew On Sun, Mar 22, 2015 at 08:59:15PM +0300, Стас Цымбалов wrote: > This patch fixes incorrect sound positioning in dsound. > As of now, angle to sound source is calculated as angle between > vDistance and vOrientFront. > This leads to incorrect results for all sources that are not in the > same plane as speakers. > In extreme case: for sources directly above or below origin, angle is > calculated to -90 degrees, and they are played in the left speaker. > > This patch changes angle calculation: angle to sound source is > calculated as angle between vDistance and plane given by vectors > vOrientFront and vOrientTop. > --- > dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > From 1ebe3761b0d6acfca58cec17472336a05b7f2679 Mon Sep 17 00:00:00 2001 > From: Stas Cymbalov <dummyunit(a)gmail.com> > Date: Sun, 22 Mar 2015 18:22:49 +0300 > Subject: dsound: Fix angle to sound source calculation. > > --- > dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > > diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c > index 9a0226a..ffd4d45 100644 > --- a/dlls/dsound/sound3d.c > +++ b/dlls/dsound/sound3d.c > @@ -112,7 +112,6 @@ static inline D3DVALUE AngleBetweenVectorsRad (const D3DVECTOR *a, const D3DVECT > > cos = product/(la*lb); > angle = acos(cos); > - if (cos < 0.0f) { angle -= M_PI; } > TRACE("angle between (%f,%f,%f) and (%f,%f,%f) = %f radians (%f degrees)\n", a->x, a->y, a->z, b->x, > b->y, b->z, angle, RadToDeg(angle)); > return angle; > @@ -264,16 +263,20 @@ void DSOUND_Calc3DBuffer(IDirectSoundBufferImpl *dsb) > else > { > vLeft = VectorProduct(&dsb->device->ds3dl.vOrientFront, &dsb->device->ds3dl.vOrientTop); > - flAngle = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > - flAngle2 = AngleBetweenVectorsRad(&vLeft, &vDistance); > - > - /* AngleBetweenVectorsRad performs a dot product, which gives us the cosine of the angle > - * between two vectors. Unfortunately, because cos(theta) = cos(-theta), we've no idea from > - * this whether the sound is to our left or to our right. We have to perform another dot > - * product, with a vector at right angles to the initial one, to get the correct angle. > - * The angle should be between -180 degrees and 180 degrees. */ > - if (flAngle < 0.0f) { flAngle += M_PI; } > - if (flAngle2 > 0.0f) { flAngle = -flAngle; } > + /* To calculate angle to sound source we need to: > + * 1) Get angle between vDistance and a plane on which angle to sound source should be 0. > + * Such a plane is given by vectors vOrientFront and vOrientTop, and angle between vector > + * and a plane equals to M_PI_2 - angle between vector and normal to this plane (vLeft in this case). > + * 2) Determine if the source is behind or in front of us by calculating angle between vDistance > + * and vOrientFront. > + */ > + flAngle = AngleBetweenVectorsRad(&vLeft, &vDistance); > + flAngle2 = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > + if (flAngle2 > M_PI_2) > + flAngle = -flAngle; > + flAngle -= M_PI_2; > + if (flAngle < -M_PI) > + flAngle += 2*M_PI; > } > TRACE("panning: Angle = %f rad, lPan = %d\n", flAngle, dsb->volpan.lPan); > > -- > 2.0.5 > >

1 0

Re: [PATCH 4/4] ddraw/tests: Port test_color_fill to earlier versions.
by Henri Verbeet March 23, 2015

March 23, 2015

On 20 March 2015 at 12:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + if (tests[i].caps & DDSCAPS_ZBUFFER) > + { > + surface_desc.dwFlags &= ~DDSD_PIXELFORMAT; > + surface_desc.dwFlags |= DDSD_ZBUFFERBITDEPTH; > + U2(surface_desc).dwZBufferBitDepth = get_device_z_depth(device); > + } > + > + hr = IDirectDraw2_CreateSurface(ddraw, &surface_desc, &surface, NULL); > + ok(SUCCEEDED(hr), "Failed to create surface, hr %#x, surface %s.\n", hr, tests[i].name); > + This crashes for me: ddraw2.c:7654: Test failed: Failed to create surface, hr 0x88760091, surface sysmem zbuffer. ddraw2.c:7654: this is the last test seen before the exception ddraw2: unhandled exception c0000005 at 00437C9D And similarly for ddraw1: ddraw1.c:6636: Test failed: Failed to create surface, hr 0x88760091, surface sysmem zbuffer. ddraw1.c:6636: this is the last test seen before the exception ddraw1: unhandled exception c0000005 at 004167BD

1 0

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

March 23, 2015

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 March 23, 2015

March 23, 2015

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 March 23, 2015

March 23, 2015

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 March 23, 2015

March 23, 2015

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 March 23, 2015

March 23, 2015

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 March 23, 2015

March 23, 2015

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 March 23, 2015

March 23, 2015

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 March 22, 2015

March 22, 2015

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 March 22, 2015

March 22, 2015

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 March 22, 2015

March 22, 2015

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