wine-devel August 2016

55 participants
282 discussions

Re: [v1 1/5] winejoystick.drv: Add functionality to disable joystick via registry

by Bruno Jesus

On Sun, Aug 28, 2016 at 3:18 AM, David Lawrie <david.dljunk(a)gmail.com> wrote: > Adds device_disabled_registry, helper functions to shared joystick code Hi, thanks for working on this. The problem with this series is that you are introducing dead code in patches 1, 2 and 3. As the code is not used anywhere until patch 5. Patch 4 also adds dead code that is only used in patch 5. IMO you should merge patches 1,2,3 into a single patch and also 4 and 5 into second patch. This will make the dead code will last a single commit. Best wishes, Bruno

7 years, 8 months

Re: [PATCH 1/2] rbtree.h: Store parent in each entry and use that to manipulate the tree without a stack.

by Henri Verbeet

On 10 August 2016 at 16:01, Jacek Caban <jacek(a)codeweavers.com> wrote: > include/wine/rbtree.h | 376 > +++++++++++++++++++++++++++----------------------- > 1 file changed, 200 insertions(+), 176 deletions(-) > Since this patch was assigned to me... I think this patch has quite a number of unrelated changes, to the point that the patch touches over half of the lines in the file and I think deletion for example ends up just being a different algorithm. And while the aforementioned means I didn't look at everything in quite the amount of detail that would otherwise be appropriate, I do think some of those changes make things overly complicated. For example, a straightforward modification to wine_rb_put() would turn it into something like the following: static inline int wine_rb_put(struct wine_rb_tree *tree, const void *key, struct wine_rb_entry *entry) { struct wine_rb_entry **node = &tree->root; struct wine_rb_entry *parent = *node; while (*node) { int c; if (!(c = tree->functions->compare(key, *node))) return -1; parent = *node; if (c < 0) node = &(*node)->left; else node = &(*node)->right; } entry->flags = WINE_RB_FLAG_RED; entry->parent = parent; entry->left = NULL; entry->right = NULL; *node = entry; wine_rb_fixup(&tree->root, entry); tree->root->flags &= ~WINE_RB_FLAG_RED; return 0; } I think that's much clearer than what this patch does with wine_rb_put().

7 years, 8 months

Re: dxdiagn: Do fill DMI information on Linux

by Chris Robinson

On 08/28/2016 02:50 AM, Ruslan Kabatsayev wrote: > This patch makes previously empty fields szSystemManufacturerEnglish, > szSystemManufacturerEnglish and szBIOSEnglish in DxDiag filled with the > DMI information. This is the same information I get on my test Windows > system. > Currently this is only implemented for Linux, on other platforms > the fields remain empty. Are there functions to get this info in the Windows API? If so, it may be worth using/implementing those API calls, instead of reading it directly from the host like this.

7 years, 8 months

Issues if GLX_SWAP_METHOD_OML is not fully supported

by Fabian Maurer

Hello, I have an OpenGL program that tries to use WGL_SWAP_METHOD, but while my graphics card supports GLX_OML_swap_method, no pixelformat supports its value GLX_SWAP_EXCHANGE_OML. Is this a graphics driver issue? I'm using the most recent open source mesa drivers. Attached a patch proposal to deal with the issue in wine, but I'm not sure if this is the right course of action to take. Fabian Maurer

7 years, 8 months

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

7 years, 8 months

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

7 years, 8 months

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

7 years, 8 months

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

7 years, 8 months

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

7 years, 8 months

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 ''

7 years, 8 months

← Newer
1
2
3
4
5
6
7
...
29
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel August 2016