January 2013 - Wine-Devel - list.winehq.org

Re: [3/3] wmiutils/tests: Add more tests.
by Marvin Jan. 3, 2013

Jan. 3, 2013

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=23729 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: comctl32/listview: Improve LVM_GETSUBITEMRECT implementation for out-of-bounds item indices
by Marvin Jan. 3, 2013

Jan. 3, 2013

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=23728 Your paranoid android. === W2K8SE (32 bit listview) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

2 1

Re: [PATCH 2/2] atl100: Added AtlUnadvise implementation
by Marvin Jan. 3, 2013

Jan. 3, 2013

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=23726 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 1/2] atl100: Added AtlAdvise implementation
by Marvin Jan. 3, 2013

Jan. 3, 2013

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=23725 Your paranoid android. === W2K8SE (32 bit atl) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

Re: [3/4] windowscodecs: Implement CreateBitmapFromMemory.
by Dmitry Timoshkov Jan. 3, 2013

Jan. 3, 2013

Vincent Povirk <madewokherd(a)gmail.com> wrote: > + hr = IWICBitmap_Lock(bitmap, NULL, WICBitmapLockWrite, &lock); > + if (SUCCEEDED(hr)) > + { > + UINT buffersize; > + BYTE *buffer; > + > + hr = IWICBitmapLock_GetDataPointer(lock, &buffersize, &buffer); > + > + memcpy(buffer, pbBuffer, uiHeight * cbStride); > + > + IWICBitmapLock_Release(lock); > + } It's better to actually check return value of IWICBitmapLock_GetDataPointer before memecpy(), or if that's not supposed to fail drop 'hr' assignment. My approach to pass buffer directly to BitmapImpl_Create looks much simpler than fiddling with IWICBitmap_Lock IMHO. -- Dmitry.

2 2

wine-1.5.20 reversion compared to 1.5.19 and previous; MinGW/gcc 4.7.0 segfaults under wineconsole
by Alan W. Irwin Jan. 2, 2013

Jan. 2, 2013

The subject line pretty much says it all. Running MinGW/gcc under wineconsole for any simple test programme should demonstrate the issue for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large selection of 1.5.x and MinGW versions I have tried over the last year or so. I would be happy to supply more details if there is any difficulty replicating this reversion. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

3 7

Re: [PATCH] ntdll/tests: Fix SYSTEM_CACHE_INFORMATION failures [try 2]
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23718 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH] ntdll/tests: Fix SYSTEM_CACHE_INFORMATION failures on WIN64
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23712 Your paranoid android. === W2KPROSP4 (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) === WXPPROSP3 (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) === W2K3R2SESP2 (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) === WVISTAADM (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) info.c:556: Test failed: 0: got 0xc0000004 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) === W2K8SE (32 bit info) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation === W7PRO (32 bit info) === info.c:550: Test failed: 35: got 0x0 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36) info.c:556: Test failed: 0: got 0xc0000004 and 12 (expected STATUS_INFO_LENGTH_MISMATCH and 36)

1 0

Re: [3/4] windowscodecs: Implement CreateBitmapFromMemory.
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23710 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [2/4] windowscodecs: Test whether CreateBitmapFromMemory stride is stored.
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23709 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH] winebuild: Use Clang to assemble if its integrated assembler is being used.
by André Hentschel Jan. 2, 2013

Jan. 2, 2013

Am 02.01.2013 02:56, schrieb Charles Davis: > --- a/tools/winebuild/utils.c > +++ b/tools/winebuild/utils.c > @@ -345,10 +345,22 @@ struct strarray *get_as_command(void) > > if (!as_command) > { > +#ifdef CLANG_AS > + /* The native assembler might not support CFI pseudo-ops, > + * but clang does. So if we were compiled with > + * clang, we should assemble with clang, too. > + */ > + static const char * const commands[] = { CLANG_AS, "clang", NULL }; > + as_command = find_tool( "clang", commands ); > +#else > static const char * const commands[] = { "gas", "as", NULL }; > as_command = find_tool( "as", commands ); > +#endif > } > strarray_add_one( args, as_command ); > +#ifdef CLANG_AS > + strarray_add( args, "-xassembler", "-c", NULL ); > +#endif > > if (force_pointer_size) > { > Not sure if you can do it like that, as i understand it winebuild should always be able to crosscompile something, these ifdefs would destroy that feature. -- Best Regards, André Hentschel

3 2

[website] Are we doing something wrong with our secure connections?
by André Hentschel Jan. 2, 2013

Jan. 2, 2013

Hi, FWIW i have just seen: https://www.ssllabs.com/ssltest/analyze.html?d=testbot.winehq.org&hideResul… https://www.ssllabs.com/ssltest/analyze.html?d=test.winehq.org&hideResults=… https://www.ssllabs.com/ssltest/analyze.html?d=winehq.org&hideResults=on&ig… which tells me we have some problems with secure website connection, the question is, do we need more security here? -- Best Regards, André Hentschel

2 1

Re: winebuild: Add configure option to use llvm-mc as assembler.
by Charles Davis Jan. 2, 2013

Jan. 2, 2013

On Jan 1, 2013, at 9:35 AM, Per Johansson wrote: > Needed to build with clang on OS X, the normal as program can't parse clang > output. > It's a configure option since llvm-mc takes different options than the normal > assembler, and on OS X is most often installed by a different name > (llvm-mc-mp-3.1 in my case). But llvm-mc isn't a tool intended to be used by the end user. It's an LLVM developer's tool intended to be used to test and play with LLVM's MC library (which Clang uses to implement its integrated assembler). The help output even says "llvm machine code playground". That's why Apple doesn't distribute it with Xcode. The right thing IMO is to test if we're compiling with Clang. If we are, then we should test if Clang is using its integrated assembler; if it is, then we should invoke Clang instead of the system assembler to assemble. This way, the user doesn't have to pass yet another option to configure in case he's using Clang. I have a patch to hack-fix winebuild to invoke Clang if we're being compiled by Clang; I can fix it to test for Clang and Clang's integrated assembler in configure and send it to the list--something I really should've done a while ago. Chip > --- > configure.ac | 8 ++++++++ > tools/winebuild/build.h | 6 +++++- > tools/winebuild/import.c | 4 ++-- > tools/winebuild/res32.c | 2 +- > tools/winebuild/utils.c | 22 +++++++++++++++++----- > 5 files changed, 33 insertions(+), 9 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 620ad07..84232e0 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -59,6 +59,7 @@ AC_ARG_WITH(jpeg, AS_HELP_STRING([--without-jpeg],[do not use JPEG]), > [if test "x$withval" = "xno"; then ac_cv_header_jpeglib_h=no; fi]) > AC_ARG_WITH(ldap, AS_HELP_STRING([--without-ldap],[do not use LDAP]), > [if test "x$withval" = "xno"; then ac_cv_header_ldap_h=no; ac_cv_header_lber_h=no; fi]) > +AC_ARG_WITH(llvm-mc, AS_HELP_STRING([--with-llvm-mc=NAME],[Use llvm-mc as assembler])) > AC_ARG_WITH(mpg123, AS_HELP_STRING([--without-mpg123],[do not use the mpg123 library]), > [if test "x$withval" = "xno"; then ac_cv_header_mpg123_h=no; fi]) > AC_ARG_WITH(openal, AS_HELP_STRING([--without-openal],[do not use OpenAL]), > @@ -294,6 +295,13 @@ AC_CHECK_PROGS(CONVERT, convert, false) > AC_CHECK_PROGS(ICOTOOL, icotool, false) > AC_CHECK_PROGS(MSGFMT, msgfmt, false) > > +dnl Check if user wants llvm-mc > +if test "x${with_llvm_mc:-no}" != "xno" > +then > + if test "${with_llvm_mc}" = "yes"; then with_llvm_mc=llvm-mc; fi > + AC_DEFINE_UNQUOTED(LLVM_MC, ["${with_llvm_mc}"], [Define to name of llvm-mc program, if preferred.]) > +fi > + > if test "x$enable_maintainer_mode" != "xyes" > then > AC_SUBST([MAINTAINER_MODE],[\#]) > diff --git a/tools/winebuild/build.h b/tools/winebuild/build.h > index 05adf31..71e87f6 100644 > --- a/tools/winebuild/build.h > +++ b/tools/winebuild/build.h > @@ -209,6 +209,10 @@ struct strarray > #define IMAGE_SUBSYSTEM_WINDOWS_CUI 3 > #define IMAGE_SUBSYSTEM_WINDOWS_CE_GUI 9 > > +/* find_tool flags */ > + > +#define FT_SKIP_TARGET_ALIAS 1 > + > /* global functions */ > > #ifndef __GNUC__ > @@ -246,7 +250,7 @@ extern int output( const char *format, ... ) > extern void output_cfi( const char *format, ... ) > __attribute__ ((__format__ (__printf__, 1, 2))); > extern void spawn( struct strarray *array ); > -extern char *find_tool( const char *name, const char * const *names ); > +extern char *find_tool( const char *name, const char * const *names, int flags ); > extern struct strarray *get_as_command(void); > extern struct strarray *get_ld_command(void); > extern const char *get_nm_command(void); > diff --git a/tools/winebuild/import.c b/tools/winebuild/import.c > index c73b86c..821b5b8 100644 > --- a/tools/winebuild/import.c > +++ b/tools/winebuild/import.c > @@ -1325,14 +1325,14 @@ void output_import_lib( DLLSPEC *spec, char **argv ) > fclose( output_file ); > output_file = NULL; > > - strarray_add( args, find_tool( "dlltool", NULL ), "-k", "-l", output_file_name, "-d", def_file, NULL ); > + strarray_add( args, find_tool( "dlltool", NULL, 0 ), "-k", "-l", output_file_name, "-d", def_file, NULL ); > spawn( args ); > strarray_free( args ); > > if (argv[0]) > { > args = strarray_init(); > - strarray_add( args, find_tool( "ar", NULL ), "rs", output_file_name, NULL ); > + strarray_add( args, find_tool( "ar", NULL, 0 ), "rs", output_file_name, NULL ); > strarray_addv( args, argv ); > spawn( args ); > strarray_free( args ); > diff --git a/tools/winebuild/res32.c b/tools/winebuild/res32.c > index 729aa2f..bddca83 100644 > --- a/tools/winebuild/res32.c > +++ b/tools/winebuild/res32.c > @@ -682,7 +682,7 @@ void output_res_o_file( DLLSPEC *spec ) > free( output_buffer ); > > args = strarray_init(); > - strarray_add( args, find_tool( "windres", NULL ), "-i", res_file, "-o", output_file_name, NULL ); > + strarray_add( args, find_tool( "windres", NULL, 0 ), "-i", res_file, "-o", output_file_name, NULL ); > spawn( args ); > strarray_free( args ); > > diff --git a/tools/winebuild/utils.c b/tools/winebuild/utils.c > index 09f9b73..0fe24a9 100644 > --- a/tools/winebuild/utils.c > +++ b/tools/winebuild/utils.c > @@ -276,7 +276,7 @@ void spawn( struct strarray *args ) > } > > /* find a build tool in the path, trying the various names */ > -char *find_tool( const char *name, const char * const *names ) > +char *find_tool( const char *name, const char * const *names, int flags ) > { > static char **dirs; > static unsigned int count, maxlen; > @@ -286,7 +286,7 @@ char *find_tool( const char *name, const char * const *names ) > unsigned int i, len; > struct stat st; > > - if (target_alias) return strmake( "%s-%s", target_alias, name ); > + if (target_alias && !(flags & FT_SKIP_TARGET_ALIAS)) return strmake( "%s-%s", target_alias, name ); > > if (!dirs) > { > @@ -345,11 +345,22 @@ struct strarray *get_as_command(void) > > if (!as_command) > { > +#ifdef LLVM_MC > + as_command = find_tool( LLVM_MC, NULL, FT_SKIP_TARGET_ALIAS ); > +#else > static const char * const commands[] = { "gas", "as", NULL }; > - as_command = find_tool( "as", commands ); > + as_command = find_tool( "as", commands, 0 ); > +#endif > } > strarray_add_one( args, as_command ); > > +#ifdef LLVM_MC > + strarray_add( args, "-filetype", "obj", NULL); > + if (target_alias) > + strarray_add( args, "-triple", target_alias, NULL); > + else if (force_pointer_size) > + strarray_add( args, "-arch", (force_pointer_size == 8) ? "x86_64" : "x86", NULL ); > +#else > if (force_pointer_size) > { > switch (target_platform) > @@ -370,6 +381,7 @@ struct strarray *get_as_command(void) > break; > } > } > +#endif > > if (cpu_option) strarray_add_one( args, strmake("-mcpu=%s", cpu_option) ); > return args; > @@ -382,7 +394,7 @@ struct strarray *get_ld_command(void) > if (!ld_command) > { > static const char * const commands[] = { "ld", "gld", NULL }; > - ld_command = find_tool( "ld", commands ); > + ld_command = find_tool( "ld", commands, 0 ); > } > strarray_add_one( args, ld_command ); > > @@ -417,7 +429,7 @@ const char *get_nm_command(void) > if (!nm_command) > { > static const char * const commands[] = { "nm", "gnm", NULL }; > - nm_command = find_tool( "nm", commands ); > + nm_command = find_tool( "nm", commands, 0 ); > } > return nm_command; > } > -- > 1.8.0 > > >

2 5

Re: aclocal: Use -Werror when checking compiler flags.
by Alexandre Julliard Jan. 2, 2013

Jan. 2, 2013

Per Johansson <per(a)morth.org> writes: > This makes clang exit with error on unsupported warnings. You'd need to check if -Werror is supported first. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 7/7] d3dcompiler43/tests: Don't use IUnknown_Release(). (try 3)
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23693 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 3/7] d3dx9: Handle invalid byte code in D3DXGetShaderConstantTableEx(). (try 3)
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23692 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 2/7] d3dx9: Always set the table = NULL in D3DXGetShaderConstantTableEx(). (try 3)
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23691 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 1/7] d3dx9: Handle invalid byte code in D3DXFindShaderComment().
by Matteo Bruni Jan. 2, 2013

Jan. 2, 2013

2013/1/1 Rico Schüller <kgbricola(a)web.de>: > --- > dlls/d3dx9_36/shader.c | 16 +++++++++++----- > dlls/d3dx9_36/tests/shader.c | 21 +++++++++++++++++++++ > 2 Dateien geändert, 32 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-) > +static inline BOOL is_valid_bytecode(DWORD token) +{ + token &= 0xFFFF0000; + return token == 0xFFFF0000 || token == 0xFFFE0000; +} This series looks good to me, but I'd prefer you use lowercase hexadecimal constants in the future.

2 1

Re: d3dcompiler_43: Avoid signed-unsigned integer comparisons
by Matteo Bruni Jan. 2, 2013

Jan. 2, 2013

2013/1/1 Andrew Talbot <andrew.talbot(a)talbotville.com>: > Changelog: > d3dcompiler_43: Avoid signed-unsigned integer comparisons. > > diff --git a/dlls/d3dcompiler_43/bytecodewriter.c b/dlls/d3dcompiler_43/bytecodewriter.c > index d10f6bc..17289d2 100644 > --- a/dlls/d3dcompiler_43/bytecodewriter.c > +++ b/dlls/d3dcompiler_43/bytecodewriter.c > @@ -609,7 +609,7 @@ static void write_declarations(struct bc_writer *This, > } > > static void write_const(struct constant **consts, int num, DWORD opcode, DWORD reg_type, struct bytecode_buffer *buffer, BOOL len) { > - DWORD i; > + int i; > DWORD instr_def = opcode; > const DWORD reg = (1<<31) | > ((reg_type << D3DSP_REGTYPE_SHIFT) & D3DSP_REGTYPE_MASK) | > I think it's better if you turn the num parameter into an unsigned int (or DWORD) instead.

1 0

Re: [7/7] wmiutils: Add tests. (try 2)
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23688 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [7/7] wmiutils: Add tests.
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23686 Your paranoid android. === WNT4WSSP6 (32 bit path) === path.c:102: Test failed: got 80040154 path: unhandled exception c0000005 at 00401303 === W2KPROSP4 (32 bit path) === path.c:102: Test failed: got 80040154 path: unhandled exception c0000005 at 00401303

1 0

Re: [PATCH] ddraw: Don't discard buffers that haven't been used in draws
by Henri Verbeet Jan. 2, 2013

Jan. 2, 2013

On 2 January 2013 12:26, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Fixes bug 32485. I'm sure we've had this discussion wrt. commit messages before, but this tells me just about nothing about what problem this patch is supposed to fix, or why this is the correct solution. Also, do you have tests for this?

2 1

Re: [11/12] kernel32: Add support for {Get|Set}NamedPipeHandleState().
by Marvin Jan. 2, 2013

Jan. 2, 2013

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=23681 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: xbox 360 emulation with logitech cordless and dinput joy disable
by Stefan Dösinger Jan. 1, 2013

Jan. 1, 2013

Hi, The patch needs a few improvements before it can be accepted into Wine. I can't comment on the dinput / xinput specifics of the patch, so this is a non- exhaustive list of general suggestions. Concerning the big picture, this patch needs a few discussions about xinput.dll design. There have been some discussions about that in the past, and I hope that some dinput devs can help out. Am Dienstag, 12. Juni 2012, 23:48:53 schrieb Giovanni Ongaro: > From: root <root(a)joe.(none)> Please configure git correctly, see http://wiki.winehq.org/GitWine section 3.3. Also consider using a non-root user, but that's your personal setup, so not really my business. > + if (getenv("LINIXFORCENOJOY") != NULL) return FALSE; /*JoeFix disable joystick*/ The problem with dinput vs xinput conflicts should probably be solved in a different manner. That aside, such configurations are usually done via registry keys. Also comments like /* I changed this here */ are useless, the git history stores this information anyway. > + <...> //JoeFix DEAD ZONE This is a C++ comment and not allowed in Wine. See http://wiki.winehq.org/SubmittingPatches > + fdJoy=open("/dev/input/js0",O_RDONLY | O_NONBLOCK); Xinput.dll should not open joystick devices directy, and definitely not a hardcoded one. I don't know if there's consensus about how xinput should be implemented, but basing it on top of dinput might be a start. A good start would be to write a few tests to test how Windows announces(or doesn't announce) Xbox gamepads and other gamepads/joysticks to games. My understanding is that xinput.dll only works for Xbox gamepads. Do those show up in dinput on Windows? > +#define DEAD_ZONE 4096 > ... > + if (e.number == 4) { > + if (e.value == 1) { > + FIXME("TRIGGER LEFT PRESSED\n"); > + pState->Gamepad.bLeftTrigger=32767; > + } > + else { > + pState->Gamepad.bLeftTrigger=0; > + } > ... > +#define JOYMAX 30000 > +#define JOYMIN -30000 The hardcoded numbers look questionable. The 4 and 1 are probably specific to the joystick, the 32767 might have a symbolic name like XINPUT_MAX or something. A part of this seems to be needed due to the attempt to emulate an xbox gamepad with a different device. Personally I'm not opposed to doing that, and you might need some device specific tricks to pull this off. However, this needs a more structured approach than hardcoding the values needed for one specific Logitech device in the code. Best regards, Stefan

3 2

Re: [PATCH] dsound: rework ugly mixer logic
by Andrew Eikum Jan. 1, 2013

Jan. 1, 2013

On Sat, Dec 29, 2012 at 01:24:03AM +0100, Maarten Lankhorst wrote: > + if(!maxq){ > + /* nothing to do! */ > + LeaveCriticalSection(&device->mixlock); > + return; > } This was removed in 8ba4090fc304993. It breaks starting the device in some situations (write primary mode iirc). > + if (native) { > + void *buffer = NULL; > + > + hr = IAudioRenderClient_GetBuffer(device->render, maxq / block, (void*)&buffer); > + if(FAILED(hr)){ > + WARN("GetBuffer failed: %08x\n", hr); > + LeaveCriticalSection(&device->mixlock); > + return; > + } I think this (mixing directly to RenderClient and skipping WaveQueue) could be split into a separate patch. > hres = IAudioClient_Initialize(device->client, > AUDCLNT_SHAREMODE_SHARED, AUDCLNT_STREAMFLAGS_NOPERSIST | > - AUDCLNT_STREAMFLAGS_EVENTCALLBACK, prebuf_rt, 0, device->pwfx, NULL); > + AUDCLNT_STREAMFLAGS_EVENTCALLBACK, 800000, 0, device->pwfx, NULL); ... > + frames = (UINT64)device->pwfx->nSamplesPerSec * 800000 / 10000000; Could you #define the 800000? Anyway, I gave it a test on ALSA+Pulse and didn't find any issues. I'll test the other backends when you resubmit. Andrew

2 3