Bug 12507

Summary: SendCoreEvents leads to duplicate mouse events
Product: xorg Reporter: Brice Goglin <brice.goglin>
Component: Input/MouseAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED NOTABUG QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: peter.hutterer
Version: 7.3 (2007.09)   
Hardware: Other   
OS: All   
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443441
Whiteboard:
i915 platform: i915 features:

Description Brice Goglin 2007-09-21 03:02:55 UTC
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.
Comment 1 Brice Goglin 2007-09-21 03:20:11 UTC
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?
Comment 2 Peter Hutterer 2007-09-21 03:56:05 UTC
(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. 

Comment 3 Peter Hutterer 2007-09-21 04:01:56 UTC
(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. 
Comment 4 Daniel Stone 2007-09-21 06:18:57 UTC
(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.