Reported by Ben Pearre in the Debian BTS yesterday. He's using Xorg 7.3. His xorg.conf is available at the URL above. He says: On my Thinkpad T41 (latest Unstable as of 20 minutes ago), I see the reported symptoms with the most recent upgrade (previous upgrade was a few weeks ago; no problems at that time). xev reports duplicate mouse events. Here is its output from a single left button click: ButtonPress event, serial 28, synthetic NO, window 0x1e00001, root 0x46, subw 0x0, time 5561272, (31,150), root:(656,179), state 0x0, button 1, same_screen YES ButtonPress event, serial 28, synthetic NO, window 0x1e00001, root 0x46, subw 0x0, time 5561272, (31,150), root:(656,179), state 0x100, button 1, same_screen YES ButtonRelease event, serial 28, synthetic NO, window 0x1e00001, root 0x46, subw 0x0, time 5561351, (31,150), root:(656,179), state 0x100, button 1, same_screen YES ButtonRelease event, serial 28, synthetic NO, window 0x1e00001, root 0x46, subw 0x0, time 5561351, (31,150), root:(656,179), state 0x0, button 1, same_screen YES Those are real duplicates. Cutting and pasting that with the middle button resulted in the same content twice (ie. eight events) but that I deleted 4 of them, leaving what you see. This happens whenever I have both "Clit" and "Generic Mouse" enabled in xorg.conf:ServerLayout (using "builtin"), but does not happen with just "Clit" and "TouchPad". Do you want the output from the remaining combinations? I do not have a generic mouse hooked up.
Update URL above. Could be caused by events coming through both /dev/input/mice and /dev/psaux. Did the behavior of the server regarding this change between 1.3 and 1.4?
(In reply to comment #1) > Could be caused by events coming through both /dev/input/mice and /dev/psaux. > Did the behavior of the server regarding this change between 1.3 and 1.4? sounds like it. would help if xorg.conf is available. Alternatively, try out Option "AllowEmptyInput" True in the server layout, this should stop the server from automatically adding the generic mouse.
(In reply to comment #1) > Update URL above. > > Could be caused by events coming through both /dev/input/mice and /dev/psaux. > Did the behavior of the server regarding this change between 1.3 and 1.4? whoops. didn't see the URL before. yes, the config is screwed. he will get the same event from /dev/input/mouse0 and /dev/input/mice. X has no way of knowing that this is the same device, so it happily processes them.
(In reply to comment #3) > yes, the config is screwed. he will get the same event from /dev/input/mouse0 > and /dev/input/mice. X has no way of knowing that this is the same device, so > it happily processes them. This is why the evdev driver has EVIOCGRAB, which removes the mouse from the set of devices sending to /dev/input/mice.
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.