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

Re: [01/10] msi: Ignore invalid upgrade codes in the PublishProduct action.

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=10211 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:6052: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

March 30, 2011

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > OK. > > How do you propose to do that? The way this is done on Linux, it's > probably fine to just build up/tear down an entry for each device that > HAL/udev detects, but DiskArbitration only handles disks (and not other > types of SCSI devices) on Mac. I don't think we care about other types of devices at this point. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2011

Fwd: [PATCH 2/5] d3dx9_36: Implemented ID3DXConstantTable_SetIntArray and ID3DXConstantTable_SetInt (Try 5)

by Travis Athougies

>> Ints and floats are represented differently and so, if we want to put >> an integer array into floating point registers, we need to have casts. >> If you were to simply call SetFloatArray, you would get nonsense >> values in the floating point registers. > > Even using casts will fall foul of the C aliasing rules - which > mean that the compiler can assume that a read of type will not be > modified by a write to a different type so can be reorderd (unless > one of the types is 'char'). > Exactly. Which is why I am not ever casting int pointers to float pointers as Rico suggested. Instead I'm looping through the array and casting each int to a float, which should invoke the machinery necessary to convert from the bit representation of an int to that of a float. > Not only that, but there are systems that will fault is an invalid > FP bit pattern is loaded into an FP register. > If I'm casting ints to floats (and not int pointers to float pointers) I don't see how this could be an issue. Travis -- Travis Athougies

March 30, 2011

Re: [RFC] dinput: Length can actually be 0.

by Daniel Remenak

On Tue, Mar 29, 2011 at 1:57 PM, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > (Sorry for sending to wine-patches initially, it was intended for wnie-devel.) > > This fixes force feedback devices slamming for 10ms at full strength, as > attack is an absolute value, not a factor of effect level. > > Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure > which combination) cause the effect to be not played (possibly played with 0- > level) on devices using the Linux iforce driver. This is the reason of the > comment in the code. > > But to other drivers, such as hid-ff, this code causes the device to jump as > full strength, which was reported (to me directly) for example when playing > "Live for Speed"[1] with a steering wheel having strong force feedback > (Logitech G27). > > My question: Is it acceptable to risk some regression for iforce driver (until > bug is identified) to fix other devices ? > I guess iforce devices also suffer from the too-strong attack/fade effect. > > [1] http://www.lfs.net (demo available, I didn't try it) > --- > dlls/dinput/effect_linuxinput.c | 11 +++++------ > 1 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c > index fbc5994..0154f49 100644 > --- a/dlls/dinput/effect_linuxinput.c > +++ b/dlls/dinput/effect_linuxinput.c > @@ -606,13 +606,12 @@ static HRESULT WINAPI > LinuxInputEffectImpl_SetParameters( > else env = NULL; > > if (peff->lpEnvelope == NULL) { > - /* if this type had an envelope, reset it > - * note that length can never be zero, so we set it to something > minuscule */ > + /* if this type had an envelope, reset it */ > if (env) { > - env->attack_length = 0x10; > - env->attack_level = 0x7FFF; > - env->fade_length = 0x10; > - env->fade_level = 0x7FFF; > + env->attack_length = 0; > + env->attack_level = 0; > + env->fade_length = 0; > + env->fade_level = 0; > } > } else { > /* did we get passed an envelope for a type that doesn't even have > one? */ > -- > 1.7.4.1 > My 2 cents: This patch reflects the original intent of the code. The current values are effectively a workaround for poor behavior from the iforce driver (at least in combination with the Wingman Force), which (six years ago) was the only reasonably reliable FF driver on linux. It was not clear to me at the time whether it was a driver problem or a more general evdev issue. This patch correctly fixes one part of bug 9221 (the part about acting "like a pneumatic hammer"). As a side effect, it also disables most FF on devices using the iforce driver. Today, HID FF devices are far more common than iforce devices (which AFAIK have not been manufactured since the very early 2000s). The HID driver works well (has for years), and works as documented (for instance, that patch works, as it should). I think making FF usable for HID devices is worth it; perhaps it will even spur someone to fix envelope support for the iforce driver. Regards, Daniel Remenak

March 30, 2011

Re: today's git failed to build for me

by Francois Gouget

On Tue, 29 Mar 2011, Susan Cragin wrote: > I just downloaded today's git and tried to build it. The following are > the make errors in the terminal output. Below that, separated by a > line, are the installation errors. > > make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' > gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c > audio.c: In function ‘JACK_DriverProc’: > audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) > audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in > audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ > audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) This patch will fix it: http://www.winehq.org/pipermail/wine-patches/2011-March/100389.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

March 30, 2011

Re: today's git failed to build for me

by Austin English

On Wed, Mar 30, 2011 at 01:16, Susan Cragin <susancragin(a)earthlink.net> wrote: > I just downloaded today's git and tried to build it. The following are the make errors in the terminal output. Below that, separated by a line, are the installation errors. > > make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' > gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c > audio.c: In function ‘JACK_DriverProc’: > audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) > audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in > audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ > audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) > make[1]: *** [audio.o] Error 1 > make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' > make: *** [dlls/winejack.drv] Error 2 > > ------------------------------------------ > > make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' > gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c > audio.c: In function ‘JACK_DriverProc’: > audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) > audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in > audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ > audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) > make[1]: *** [audio.o] Error 1 > make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' > make: *** [install] Error 2 Use http://www.winehq.org/pipermail/wine-patches/2011-March/100389.html or run configure --without-jack. -- -Austin

March 30, 2011

today's git failed to build for me

by Susan Cragin

I just downloaded today's git and tried to build it. The following are the make errors in the terminal output. Below that, separated by a line, are the installation errors. make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [dlls/winejack.drv] Error 2 ------------------------------------------ make[1]: Entering directory `/home/susan/wine/dlls/winejack.drv' gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wtype-limits -Wwrite-strings -Wpointer-arith -Wlogical-op -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o audio.o audio.c audio.c: In function ‘JACK_DriverProc’: audio.c:2419:50: error: ‘RTLD_NOW’ undeclared (first use in this function) audio.c:2419:50: note: each undeclared identifier is reported only once for each function it appears in audio.c:2443:5: warning: implicit declaration of function ‘MessageBoxA’ audio.c:2443:78: error: ‘MB_OK’ undeclared (first use in this function) make[1]: *** [audio.o] Error 1 make[1]: Leaving directory `/home/susan/wine/dlls/winejack.drv' make: *** [install] Error 2

March 30, 2011

Re: [PATCH 6/6] d3dx9: Use init function for ID3DXBuffer.

by David Adam

You mix S_OK with D3D_OK. Though they are equivalent, I think it would be better to keep the only D3D_OK notation. A+ David 2011/3/29 Rico Schüller <kgbricola(a)web.de> > --- > dlls/d3dx9_36/core.c | 36 +++++++++++++++++++++++++++--------- > 1 files changed, 27 insertions(+), 9 deletions(-) > > > > > >

March 29, 2011

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Charles Davis

On 3/29/11 4:34 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > >> From: Charles Davis <cdavis(a)mines.edu> >> >> --- >> dlls/kernel32/Makefile.in | 2 +- >> dlls/kernel32/oldconfig.c | 157 +++++++++++++++++++++++++++++++++++++++++++- >> 2 files changed, 154 insertions(+), 5 deletions(-) > > This code needs to be moved to the mountmgr first. OK. How do you propose to do that? The way this is done on Linux, it's probably fine to just build up/tear down an entry for each device that HAL/udev detects, but DiskArbitration only handles disks (and not other types of SCSI devices) on Mac. Chip

March 29, 2011

[RFC] dinput: Length can actually be 0.

by Vincent Pelletier

(Sorry for sending to wine-patches initially, it was intended for wnie-devel.) This fixes force feedback devices slamming for 10ms at full strength, as attack is an absolute value, not a factor of effect level. Daniel Remenak told me that 0-length envelopes (attack and/or fade, not sure which combination) cause the effect to be not played (possibly played with 0- level) on devices using the Linux iforce driver. This is the reason of the comment in the code. But to other drivers, such as hid-ff, this code causes the device to jump as full strength, which was reported (to me directly) for example when playing "Live for Speed"[1] with a steering wheel having strong force feedback (Logitech G27). My question: Is it acceptable to risk some regression for iforce driver (until bug is identified) to fix other devices ? I guess iforce devices also suffer from the too-strong attack/fade effect. [1] http://www.lfs.net (demo available, I didn't try it) --- dlls/dinput/effect_linuxinput.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/dlls/dinput/effect_linuxinput.c b/dlls/dinput/effect_linuxinput.c index fbc5994..0154f49 100644 --- a/dlls/dinput/effect_linuxinput.c +++ b/dlls/dinput/effect_linuxinput.c @@ -606,13 +606,12 @@ static HRESULT WINAPI LinuxInputEffectImpl_SetParameters( else env = NULL; if (peff->lpEnvelope == NULL) { - /* if this type had an envelope, reset it - * note that length can never be zero, so we set it to something minuscule */ + /* if this type had an envelope, reset it */ if (env) { - env->attack_length = 0x10; - env->attack_level = 0x7FFF; - env->fade_length = 0x10; - env->fade_level = 0x7FFF; + env->attack_length = 0; + env->attack_level = 0; + env->fade_length = 0; + env->fade_level = 0; } } else { /* did we get passed an envelope for a type that doesn't even have one? */ -- 1.7.4.1

March 29, 2011