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
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.
Vitaliy Margolen wine-devel@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).
On Mon, Jun 20, 2011 at 09:36, Alexandre Julliard julliard@winehq.org wrote:
Vitaliy Margolen wine-devel@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/adb86c5f2a2584dc8131b08d26a...). 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).
On 06/20/2011 02:31 PM, Austin English wrote:
On Mon, Jun 20, 2011 at 09:36, Alexandre Julliardjulliard@winehq.org wrote:
Vitaliy Margolenwine-devel@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/adb86c5f2a2584dc8131b08d26a...). 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.
On Mon, Jun 20, 2011 at 23:26, Vitaliy Margolen wine-devel@kievinfo.com wrote:
On 06/20/2011 02:31 PM, Austin English wrote:
On Mon, Jun 20, 2011 at 09:36, Alexandre Julliardjulliard@winehq.org wrote:
Vitaliy Margolenwine-devel@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/adb86c5f2a2584dc8131b08d26a...). 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).
On 06/20/2011 08:36 AM, Alexandre Julliard wrote:
Vitaliy Margolenwine-devel@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.
-
Alexandre Julliard -
Austin English -
Marcus Meissner -
Vitaliy Margolen