August 2016 - Wine-Devel - list.winehq.org

Re: How to link winreg.h to winejoystick.drv during compilation

by DavidL

Huh ... this is embarrassing, although pleasantly so: it just compiled and linked - I don't know why, I don't think I made any changes - but it works now. I will investigate a little bit further to see if the why is interesting and report what I might've done if so ... probably something stupid :) On Sat, Aug 27, 2016 at 2:22 AM, Marcus Meissner <meissner(a)suse.de> wrote: > On Fri, Aug 26, 2016 at 09:29:46PM -0700, DavidL wrote: > > I'm trying to add the ability to read registry keys to winejoystick.drv > > using functions like RegQueryValueExA, RegOpenKeyA, and RegCloseKey. > > However, I am getting linker errors where they are showing up as > undefined > > symbols. The changed files are attached. The > > functions get_app_key, get_config_key, and device_disabled_registry are > > copied from various files in dinput and I assumed I needed to import > > advapi32 in the makefile.in since that's what type the aforementioned > > registry functions are, but I'm obviously misunderstanding how this > works. > > Any help appreciated! > > Yes, importing advapi32 should be correct. > > What exact commandlines are generated and what are the errors? > > Ciao, Marcus >

Aug. 27, 2016

Re: Add a GUI for dxdiag program

by Aaryaman Vasishta

Hi, Thanks for your patch! I see there are still many style inconsistencies here, like "foo=bar;" and "foo = bar;" mixed together. Same for passing arguments, like "foo(bar,baz)" and "foo(bar, baz)" mixed together. Please try sticking to a single convention, it helps in code readability. There also might be an issue with the consistency of indendation on longer lines which do not fit. As long as you keep the indentation levels consistent across the file you should be fine. On Sat, Aug 27, 2016 at 1:56 PM, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > +INT_PTR CALLBACK system_tab_proc(HWND hsystab, UINT msg, WPARAM wparam, > LPARAM lparam) > +{ > + switch(msg) > + { > + case WM_COMMAND: > + switch(HIWORD(wparam)) > + { > + case BN_CLICKED: > + switch(wparam) > + { > + case IDC_WHQL_CHECKBOX: > + { > + update_dxdiag_info(); > + return TRUE; > + } > + } > + break; > There's an indentation issue here. You should still wait for others to review this before re-sending this patch though. Cheers, Aaryaman

Aug. 27, 2016

Re: How to link winreg.h to winejoystick.drv during compilation

by Marcus Meissner

On Fri, Aug 26, 2016 at 09:29:46PM -0700, DavidL wrote: > I'm trying to add the ability to read registry keys to winejoystick.drv > using functions like RegQueryValueExA, RegOpenKeyA, and RegCloseKey. > However, I am getting linker errors where they are showing up as undefined > symbols. The changed files are attached. The > functions get_app_key, get_config_key, and device_disabled_registry are > copied from various files in dinput and I assumed I needed to import > advapi32 in the makefile.in since that's what type the aforementioned > registry functions are, but I'm obviously misunderstanding how this works. > Any help appreciated! Yes, importing advapi32 should be correct. What exact commandlines are generated and what are the errors? Ciao, Marcus

Aug. 27, 2016

Re: Yet another xinput implementation for the xbox360 controller

by Bruno Jesus

On Sat, Aug 27, 2016 at 3:05 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > If you want force feedback remember to disable the (js) joystick in > the control panel. Also if you have other controller brands it must > have at least 6 axis, 11 buttons and 1 POV to work, but the mapping > has to be redone. If it has less buttons you can relax the checks in > dinput_is_good. > > Last but not least I know I should have used dinput to map the axes > values for me but I was tired of reading dinput docs and it was easy > enough to convert manually. Just replying to myself here. I updated the patch to work with non-xbox controllers, just tested with a 2 axes, 8 button controller and a ps2 + usb adapter. Broforce with 3 players working fine =)

Aug. 27, 2016

Yet another xinput implementation for the xbox360 controller

by Bruno Jesus

Hi to everybody. In order to exercise dinput (which is overly complex) I have implemented xinput using dinput. Xinput is as easy as winmm joystick support, I guess MS wanted to go back to the basics. I know that this is not really useful specially when HID kicks in but as I said it was an exercise and now I can play Broforce properly with the Xbox controller and force feedback. If you know a game that is xinput only and it does not work with this patch tests are appreciated (+xinput,+dinput). Most of the code can still be reused for HID IMO, just change the dinput functions. If you want force feedback remember to disable the (js) joystick in the control panel. Also if you have other controller brands it must have at least 6 axis, 11 buttons and 1 POV to work, but the mapping has to be redone. If it has less buttons you can relax the checks in dinput_is_good. Last but not least I know I should have used dinput to map the axes values for me but I was tired of reading dinput docs and it was easy enough to convert manually. Best wishes, Bruno

Aug. 27, 2016

Re: [PATCH 1/2] user32: Wait before getting/setting the cursor position in send_hardware_message

by Alexandre Julliard

Max Qian <public(a)maxqia.com> writes: > Signed-off-by: Max Qian <public(a)maxqia.com> > --- > dlls/user32/message.c | 20 +++++++++++++------- > include/wine/server_protocol.h | 8 ++------ > server/protocol.def | 4 ---- > server/queue.c | 5 ----- > server/request.h | 6 +----- > server/trace.c | 4 ---- > 6 files changed, 16 insertions(+), 31 deletions(-) There's a lot of complexity in the mouse input code, but it was all added for a reason. There are many games that do strange things with mouse input. If you want to remove things, you'll need to explain why you think they are no longer necessary. They were definitely necessary when I added them. That doesn't mean that it's perfect, but I think you should be looking into ways of tweaking the existing code instead of taking an axe to it. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2016

How to link winreg.h to winejoystick.drv during compilation

by DavidL

I'm trying to add the ability to read registry keys to winejoystick.drv using functions like RegQueryValueExA, RegOpenKeyA, and RegCloseKey. However, I am getting linker errors where they are showing up as undefined symbols. The changed files are attached. The functions get_app_key, get_config_key, and device_disabled_registry are copied from various files in dinput and I assumed I needed to import advapi32 in the makefile.in since that's what type the aforementioned registry functions are, but I'm obviously misunderstanding how this works. Any help appreciated! Thanks, David

Aug. 27, 2016

Bugs in gcc 5.3.0, 5.4.0 with force_align_arg_pointer

by Daniel Santos

Just to let you guys know, there's a bug in gcc 5.3 & 5.4 that causes wine's 64 bit code to be generated as if the incoming stack boundary was 8 bytes. This makes the pro/epilogues all bloaty with unaligned movups for SSE saves/restores. This can be avoided by actually *not* using force_align_arg_pointer or -mstackrealign. Note however that when using either of those, we should supply -mincoming-stack-boundary=4 so that gcc knows what alignment to force the arg pointer to... except that that is also expertly broken. I'm not aware of this actually causing any crashes or UB, just producing slower, bloaty code. There was also PR69140 that caused build breakage when the stack pointer wasn't properly aligned, but I guess this is a flaw that got exposed once force_align_arg_pointer started breaking alignment on x64 abi. Daniel

Aug. 27, 2016

Re: kernel32: Fixed handling LOCALE_NAME_USER_DEFAULT in GetLocaleInfoEx.

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=25413 Your paranoid android. === w1064 (32 bit locale) === locale.c:2554: Test failed: LCMapStringEx should fail with bad locale name locale.c:2555: Test failed: unexpected error code -559038737 locale.c:2646: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4382: Test failed: IsValidLocaleName should have failed locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4767: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4769: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2554: Test failed: LCMapStringEx should fail with bad locale name locale.c:2555: Test failed: unexpected error code -559038737 locale.c:2646: Test failed: Expected lcid == 0, got 00001000, error -559038737 locale.c:4382: Test failed: IsValidLocaleName should have failed locale.c:4384: Test failed: IsValidLocaleName should have failed locale.c:4767: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4769: Test failed: For id 7, Expected IVC, got ''

Aug. 26, 2016

Re: Add a simple 3D APIs demo

by Ruslan Kabatsayev

Hello, I've addressed most of the concerns, but would like to get some clarifications before I continue with the rest. On Mon, Aug 22, 2016 at 12:44 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > It would be better to use explicit float constants when assigning to > float variables (e.g. D3DMATERIAL). Do you mean that numeric constants are to never be implicitly converted? Or only integral->floating-point? Or maybe only double->float? > > More specific comments: I'd split this over multiple patches. You can > probably make an initial patch adding the program with no real > functionality, then multiple patches adding the various graphical API > demos. In that regard, the d3d8 / d3d9 "merged" handling via macros > seems a bit obfuscating to me. Just replicating the code twice seems > cleaner. Maybe you can create a few helper functions for the common > code. I've tried looking into splitting D3D code, but from the experience of fixing some issues like CamelCase->snake_case and similar it seems the split would be counter-productive for future changes. What I mean: the D3D 8 and 9 (as used in this code) only differ by interface version suffix and added/removed parameters in some methods (the parameters removed are zero here anyway, since the demos ideally should give identical results with different APIs), plus a few names changed. It seems to me that any change in functionality would require one to edit both D3D8 and D3D9 code in a _very_ similar way, and the differences between the split codes wouldn't be easy to understand: diff would give lots of unrelated differences, while substantial ones could be missed (resulting in subtly non-identical results). While this is inevitable between D3D and WGL, it's easily avoidable for such similar (in such basic use) APIs as D3D8 and D3D9. Do you still think the code should really be split? Regards, Ruslan

Aug. 26, 2016