Created attachment 30700 [details] Xorg.0.log Mouse jumps seemingly at random and tends to stick in the upper left corner of the screen. This behavior was not present in version 2.2.5. I've yet to find any useful log output when trying to pinpoint this(like others explained on Gentoo's Bugzilla(in URL)), so I'm at a loss trying to diagnose this.
For the record, both user who reported the Gentoo bug have the same mouse : an A4Tech X-750F. That's all we've got so far. Thanks
I get this with a A4Tech R7-70D.
Please download http://people.freedesktop.org/~whot/evtest.c, compile it with gcc -o evtest evtest.c and then run it as root against the device file. The device file is /dev/input/eventX, where X is a number. You can get the right device file by looking into /proc/bus/input/devices. Then reproduce the issue and attach the output here as an uncompressed text/plain attachment.
Created attachment 30766 [details] evtest dump
Have the same issue with A4Tech X-750F. Added evtest dump above.
Created attachment 30781 [details] evtest dump While running evtest the cursor never left the top left corner although evtest apparently detected events.
Created attachment 30843 [details] evtest dump A4-Tech XL-750BF
Created attachment 30872 [details] evtest dump I've got the same issue on Arch Linux with evdev 2.3.0 + A4Tech X-750 mouse.
a4tech x-750f [cykus@hell-lap Pobieranie]$ gcc -o evtest evtest.c [cykus@hell-lap Pobieranie]$ ./evtest /dev/input/event3 Input driver version is 1.0.0 Input device ID: bus 0x3 vendor 0x9da product 0xe version 0x110 Input device name: "A4Tech PS/2+USB Mouse" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 274 (MiddleBtn) Event code 275 (SideBtn) Event code 276 (ExtraBtn) Event code 277 (ForwardBtn) Event code 278 (BackBtn) Event code 279 (TaskBtn) Event type 2 (Relative) Event code 0 (X) Event code 1 (Y) Event code 8 (Wheel) Event code 9 (Misc) Event type 4 (Misc) Event code 4 (ScanCode) Grab succeeded, ungrabbing. Testing ... (interrupt to exit) Event: time 1257034599.410715, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257034599.410724, -------------- Report Sync ------------ Event: time 1257034599.418713, type 2 (Relative), code 0 (X), value 4 Event: time 1257034599.418720, type 2 (Relative), code 1 (Y), value -6 Event: time 1257034599.418723, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257034599.418725, -------------- Report Sync ------------ Event: time 1257034599.426708, type 2 (Relative), code 0 (X), value 9 Event: time 1257034599.426714, type 2 (Relative), code 1 (Y), value -7 Event: time 1257034599.426719, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257034599.426721, -------------- Report Sync ------------ Event: time 1257034599.434706, type 2 (Relative), code 0 (X), value 15 Event: time 1257034599.434712, type 2 (Relative), code 1 (Y), value -6
A4Tech X750-BF (very similar) laptok c # evtest /dev/input/event5 Input driver version is 1.0.0 Input device ID: bus 0x3 vendor 0x9da product 0xe version 0x110 Input device name: "A4Tech PS/2+USB Mouse" Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 274 (MiddleBtn) Event code 275 (SideBtn) Event code 276 (ExtraBtn) Event code 277 (ForwardBtn) Event code 278 (BackBtn) Event code 279 (TaskBtn) Event type 2 (Relative) Event code 0 (X) Event code 1 (Y) Event code 8 (Wheel) Event code 9 (Misc) Event type 4 (Misc) Event code 4 (ScanCode) Testing ... (interrupt to exit) Event: time 1257154710.602887, type 2 (Relative), code 0 (X), value -2 Event: time 1257154710.602899, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.602902, -------------- Report Sync ------------ Event: time 1257154710.610883, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.610891, -------------- Report Sync ------------ Event: time 1257154710.618884, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.618893, -------------- Report Sync ------------ Event: time 1257154710.634884, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.634893, -------------- Report Sync ------------ Event: time 1257154710.642883, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.642891, -------------- Report Sync ------------ Event: time 1257154710.650881, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.650888, -------------- Report Sync ------------ Event: time 1257154710.658868, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.658874, -------------- Report Sync ------------ Event: time 1257154710.666884, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.666892, -------------- Report Sync ------------ Event: time 1257154710.674879, type 2 (Relative), code 0 (X), value 1 Event: time 1257154710.674888, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.674891, -------------- Report Sync ------------ Event: time 1257154710.682885, type 2 (Relative), code 1 (Y), value -2 Event: time 1257154710.682896, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.682899, -------------- Report Sync ------------ Event: time 1257154710.690873, type 2 (Relative), code 1 (Y), value -3 Event: time 1257154710.690879, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.690882, -------------- Report Sync ------------ Event: time 1257154710.698882, type 2 (Relative), code 0 (X), value 3 Event: time 1257154710.698889, type 2 (Relative), code 1 (Y), value -3 Event: time 1257154710.698893, type 2 (Relative), code 9 (Misc), value 5 Event: time 1257154710.698895, -------------- Report Sync ------------ Event: time 1257154710.706878, type 2 (Relative), code 0 (X), value 2 Event: time 1257154710.706883, type 2 (Relative), code 1 (Y), value -1 Event: time 1257154710.706887, type 2 (Relative), code 9 (Misc), value 5
Same here on the same mouse (A4Tech X-750F). I did some tests and I found out that the first bad commit is 1f641d75edba7394201c1c53938215bae696791b by Oliver McFadden. I'm attaching 2 logs: one running on current git where I was slowly moving my mouse up but it was stubbornly "jumping" down on my screen (besides moving up of course). The second one is from the working 2.2.5 where I was trying to do similar movements. Can I help more?
Created attachment 31052 [details] evtest dump running on current git
Created attachment 31053 [details] evtest dump running on 2.2.5
(In reply to comment #11) > Can I help more? Yes, I can. I found a bug: In EvdevProcessSyncEvent() we don't initialize the v array. I don't understand the whole evdev mechanics (I spent with it only a few minutes) but I guess this mouse has a strange axis map and thus the following code from EvdevProcessValuators() could trigger a situation when v[map] contains a random value and later we process that value (if somewhere pEvdev->delta[i] was 0 here). int map = pEvdev->axis_map[i]; if (pEvdev->delta[i] && map != -1) { v[map] = pEvdev->delta[i]; if (map < first) first = map; if (map > last) last = map; } I'm attaching a patch that works for me.
Created attachment 31068 [details] [review] a patch fixing this bug
Sorry, I forgot that those values in v array aren't pointers. Attaching a patch with a correct comment.
Created attachment 31069 [details] [review] a patch fixing this bug
@Bartosz Brachaczek I've just tried evdev 2.3.0 with your patch, and it works great so far (A4 Tech X-750). Thanks a lot!
I've just gave this patch some further testings and got one issue with it. In 'freespace 2 open' whenever i click any of the mouse buttons the cursor "jumps" to right-bottom corner of the screen.
(In reply to comment #19) I can't get this game working, probably because I have no 3D acceleration with my video driver... Do you know any other situation in which this or similar error occurs? I'll attach 3 different patches (2 of them will be just hacks, used to check something), could you test if any of them work with your game? Check each one with unpatched xf86-input-evdev-2.3.0 or -git code. Pozdrawiam :-)
Created attachment 31072 [details] [review] alternative patch
Created attachment 31073 [details] [review] ugly hack #1
Created attachment 31074 [details] [review] ugly hack #2
I've tested only the first one https://bugs.freedesktop.org/attachment.cgi?id=31072 and the issue that i've encountered in freespace 2 is resolved. Everything else seems to be OK as well. I guess there is no point in testing the next 2 patches which are hacks. Dzieki wielkie ;)
OK, nice to hear that it works. I have a question to developers: In EvdevPostRelativeMotionEvents() I can see this line: xf86PostMotionEventP(pInfo->dev, FALSE, *first_v, *num_v, v + *first_v); Shouldn't the last argument be just "v", not "v + *first_v"? Look for example at the corresponding instruction in EvdevPostAbsoluteMotionEvents(). Please forgive my lack of knowledge.
sorry about the late reply. Patch looks good, thanks for this! please resubmit as a git-formatted patch with a reference to this bugreport and an explanation of the fix. For more info, see http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches. (In reply to comment #25) > I have a question to developers: > In EvdevPostRelativeMotionEvents() I can see this line: > > xf86PostMotionEventP(pInfo->dev, FALSE, *first_v, *num_v, v + *first_v); > > Shouldn't the last argument be just "v", not "v + *first_v"? Look for example > at the corresponding instruction in EvdevPostAbsoluteMotionEvents(). Please > forgive my lack of knowledge. I'd say that the absolute one should be v + *first_v as well. that's why we have the first/num_valuators. however,looking at the code there's no chance that first is ever not 0, that's why it didn't trigger yet.
Patch sent, thanks. (In reply to comment #26) > I'd say that the absolute one should be v + *first_v as well. that's why we > have the first/num_valuators. however,looking at the code there's no chance > that first is ever not 0, that's why it didn't trigger yet. OK, thanks for an explanation.
pushed as c1f16a4f59a584ab4546c2f16e20b06703042057. sorry for the delay, your email never arrived in my inbox (problem on my side), I had to pick it from the list archives.
Unfortunately, there still seem to be some issues with evdev and A4Tech mouse. Looks like pressing mouse button casues sending three xevents for each click: buttonpress motionnotify buttonrelease. This causes problems in e.g. KDE list sorting and random drag&drop triggering. This problem is already described in few threads: http://forum.kde.org/viewtopic.php?f=22&t=87677 https://bbs.archlinux.org/viewtopic.php?pid=806731#p806731 PS. I'm not sure whether i should open new bugreport, so i reopened this one.
Oh, I was absolutely sure it was KDE's fault with non-working list-sorting and random drag&drop triggering... Looking at my old patches I'm sure that the "alternative" patch (the one commited) was wrong. The first one was a fix to real problem in code (possibility to send an array with uninitialized values to X Server). The real problem with this mouse is that it posts REL_MISC events without reason and evdev treats them incorrectly as axis motion events. Attaching a patch that works for me. Bartek, please test it, particularly against freespace which had strange problems with my first patch. If everything is OK, I'll post proper patches to the mailing list.
Created attachment 37773 [details] [review] new patch
OK, thanks a lot. I'll give it a try, once i have access to my linux box.
I've just recompiled evdev with your patch applied and tested it in KDE and Freespace 2. Both seem to work like a charm - sorting in KDE works and i haven't found any problems in Freespace 2. Once again, thanks a lot for your work!
That's nice, thanks :) . If you want, please give your Tested-by: tag (http://www.mjmwired.net/kernel/Documentation/SubmittingPatches#286).
https://bugs.freedesktop.org/attachment.cgi?id=37773 Tested-by: Bartek Iwaniec <hash87@gmail.com>
committed as ed47c7f33e315f163a6aebeb3e1c8947004576fd and ec6cb31cc47eed3ccba4c906ca6c54b99136e9eb. Thanks for the patch and testing, I'm closing this as fixed again.
I've just updated my xf86-input-evdev package to 2.4.0-2 (Arch developers applied patches from git) and the bug still occurs. I've just checked it on http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/ and noticed that ed47c7f33e315f163a6aebeb3e1c8947004576fd and ec6cb31cc47eed3ccba4c906ca6c54b99136e9eb miss one part of the patch: @@ -500,7 +500,10 @@ EvdevProcessRelativeMotionEvent(InputInfoPtr pInfo, struct input_event *ev) EvdevQueueButtonClicks(pInfo, wheel_left_button, -value); break; - /* We don't post wheel events as axis motion. */ + case REL_MISC: + break; + + /* We don't post wheel/misc events as axis motion. */ default: /* Ignore EV_REL events if we never set up for them. */ if (!(pEvdev->flags & EVDEV_RELATIVE_EVENTS)) Issue is fixed again after rebuilding xf86-input-evdev with this part of the patch applied.
(In reply to comment #37) It's because that part was invalid. It was the server's fault, not evdev's. You can read the discussion on mailing list. Patch to the server is here: http://lists.x.org/archives/xorg-devel/2010-August/012053.html, though it's not yet pushed to the public repository.
OK, correct me if im wrong. This problem is resolved in evdev, but the issue itself is "fully" fixed only if i use evdev git version + patched xserver?
(In reply to comment #39) Actually there are two unrelated issues (although both are visible because of strange events sent by this mouse): 1. "Jumping" cursor: this one was fixed last year, but not the way it should be. Those two commits by me pushed to evdev recently only fix this issue correctly. 2. Sending MotionNotify when it shouldn't be sent: this one is a bug in server, according to Peter. So it has nothing to do with evdev. So our problem is "fully" fixed with evdev-2.3.1+ and X server with Peter's patch.
OK, now i understand. Thanks a lot for explanation.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.