Re: Disablin xinput2 for now?
On Mon, Jun 20, 2011 at 23:26, Vitaliy Margolen wine-de...@kievinfo.com wrote: On 06/20/2011 02:31 PM, Austin English wrote: On Mon, Jun 20, 2011 at 09:36, Alexandre Julliardjulli...@winehq.org wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). I just did a quick test with today's git (wine-1.3.22-255-g4c0c0d3) (which has http://source.winehq.org/git/wine.git/commitdiff/adb86c5f2a2584dc8131b08d26aef7c82910d0b5). Using Duke Nukem Forever, which has the mouse jumping bug (http://bugs.winehq.org/show_bug.cgi?id=27156) plain wine: I can move normally, with occasional mouse jumps. wine + GrabPointer=N: mouse spins around uncontrollably, a la bug http://bugs.winehq.org/show_bug.cgi?id=22282 wine configured with --without-xinput2: mouse movement isn't fluid at all. Instead, the only way the cursor will move is jumps in a random direction (like bug 27156, except there is no normal behavior in between the jumps). Can you check how well it works with wine-1.3.19 - before all xinput2 related changes went in? Mostly better now, wine-1.3.22-361-g0b2bd0c, though DNF is still broken (http://bugs.winehq.org/show_bug.cgi?id=27572). -- -Austin
Disablin xinput2 for now?
Hi, There seem to be regressions in xinput2 support, http://bugs.winehq.org/show_bug.cgi?id=27028 As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? Ciao, Marcus
Disablin xinput2 for now?
Hi, There seem to be regressions in xinput2 support I too have experienced various mouse trouble since approx. 1.3.18 on MacOS, using XQuartz 2.5.x or 2.6.1 -- which is much more recent than any of my Ubuntu systems (Lucid). As I've currently little time for regressions, I haven't yet turned that into bug reports (and had always hoped that Wine release N+1 would eventually make things work again). Haegemonia 2 aka. Legions of Iron seems to be fixed as of 1.3.22. Previously, the mouse flickered badly when moved and it moved like crazy along one y/x direction. As of 1.3.22, Black White 2 doesn't react to the mouse anymore. should we packagers turn off xinput2 support for the time being? There's still hope that the situation will stabilize as present bug reports are analyzed and the causes understood. I also hope somebody will update the Wiki pages, e.g. UsefulRegistryKeys to reflect new possibilities. I would believe there are some. The Wiki is the place where I'd expect to find a summary of options and hints for when a program does not work in area Y. I know where to look for some forms of audio trouble, but what do I know about mouse trouble? Before starting git bisect, I'd prefer to try out whether a few registry keys may help with the mouse. Which ones should I try? Regards, Jörg Höhle
Re: Disablin xinput2 for now?
On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. Vitaliy.
Re: Disablin xinput2 for now?
Vitaliy Margolen wine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). -- Alexandre Julliard julli...@winehq.org
Re: Disablin xinput2 for now?
On Mon, Jun 20, 2011 at 09:36, Alexandre Julliard julli...@winehq.org wrote: Vitaliy Margolen wine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). I just did a quick test with today's git (wine-1.3.22-255-g4c0c0d3) (which has http://source.winehq.org/git/wine.git/commitdiff/adb86c5f2a2584dc8131b08d26aef7c82910d0b5). Using Duke Nukem Forever, which has the mouse jumping bug (http://bugs.winehq.org/show_bug.cgi?id=27156) plain wine: I can move normally, with occasional mouse jumps. wine + GrabPointer=N: mouse spins around uncontrollably, a la bug http://bugs.winehq.org/show_bug.cgi?id=22282 wine configured with --without-xinput2: mouse movement isn't fluid at all. Instead, the only way the cursor will move is jumps in a random direction (like bug 27156, except there is no normal behavior in between the jumps). -- -Austin
Re: Disablin xinput2 for now?
On 06/20/2011 02:31 PM, Austin English wrote: On Mon, Jun 20, 2011 at 09:36, Alexandre Julliardjulli...@winehq.org wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). I just did a quick test with today's git (wine-1.3.22-255-g4c0c0d3) (which has http://source.winehq.org/git/wine.git/commitdiff/adb86c5f2a2584dc8131b08d26aef7c82910d0b5). Using Duke Nukem Forever, which has the mouse jumping bug (http://bugs.winehq.org/show_bug.cgi?id=27156) plain wine: I can move normally, with occasional mouse jumps. wine + GrabPointer=N: mouse spins around uncontrollably, a la bug http://bugs.winehq.org/show_bug.cgi?id=22282 wine configured with --without-xinput2: mouse movement isn't fluid at all. Instead, the only way the cursor will move is jumps in a random direction (like bug 27156, except there is no normal behavior in between the jumps). Can you check how well it works with wine-1.3.19 - before all xinput2 related changes went in? Vitaliy.
Re: Disablin xinput2 for now?
On 06/20/2011 08:36 AM, Alexandre Julliard wrote: Vitaliy Margolenwine-de...@kievinfo.com writes: On 06/20/2011 02:55 AM, Marcus Meissner wrote: As this might be a X.org issue, should we packagers turn off xinput2 support for the time being? If that will fix all dinput regressions - absolutely. Or add a registry option to disable xinput2. It will of course fix some regressions, and introduce new ones for things that have been fixed by the changes. Don't tell me that dinput was working perfectly before. And there is a registry option (GrabPointer). Dinput never perfectly worked before and doesn't work perfectly now. Even native has serious issues in Wine. I've lost track of all the changes you did to mouse/keyboard events, ll hooks, pointer position changes, etc. But it seems to me something broke that was working before. At least did not affect programs as much as it does now. I've seen number of programs/games that were highly sensitive to timing and order of various events. Unfortunately it was impossible to exactly replicate and/or make a test for it. And with dynamic nature of the problem it's a royal PITA to debug. In either case, it seems that what used to more-less work before doesn't work at all. Or has major problems (non-xinput2 code-path). And the new xinput2 code-path while resolving large number of issues, introduced number of other problems. So just disabling xinput2 support in any a binary build won't really help much. Vitaliy.
