I reported this bug previously to Xorg https://bugs.freedesktop.org/show_bug.cgi?id=26079 , where it was confirmed by Mathieu Marquer. Steps to reproduce. 1. $ xev | grep -v 'button [^1]' 2. repeatedly press left touchpad button until xev reports "button 2" It usually takes 10-20 repetitions of the above process for this to happen. If it does not happen, doing something else like switching windows usually helps trigger the problem again. Sometimes both button events are generated, sometimes only button 2. I can _not_ reproduce the problem with a USB mouse. I bisected the bug to commit 315eb996 (Input: psmouse - rework setting of BTN_MIDDLE capability), which is part of the 2.6.33 release. Reverting that commit from the current tip of the nouveau kernel tree v2.6.34-rc2-760-g2c9a8fe fixes the issue. wkr, Clemens --- Xorg version 7.5+3 (Debian package) Xorg synaptics driver version 1.2.1-1 (Debian package) * scripts/ver_linux output Linux darc 2.6.34-rc2-00760-g2c9a8fe #9 SMP PREEMPT Sat Apr 10 23:42:12 CEST 2010 x86_64 GNU/Linux Gnu C 4.3.4 Gnu make 3.81 binutils 2.20 util-linux 2.16.2 mount support module-init-tools 3.11 e2fsprogs 1.41.9 Linux C Library 2.10.2 Dynamic linker (ldd) 2.10.2 Procps 3.2.8 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 7.4 wireless-tools 30 Modules Loaded bridge stp llc rfcomm ipv6 kvm_intel cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_userspace cpufreq_ondemand binfmt_misc uinput bpa10x hci_uart hci_vhci btsdio microcode bcm203x usbserial ohci_hcd cifs acpi_cpufreq freq_table container sbs kvm msr cpuid sbshc display lcd led_class sco hidp bnep l2cap gspca_zc3xx gspca_main snd_pcm_oss snd_mixer_oss fuse nouveau ttm drm_kms_helper drm fan video processor iwlagn pcmcia thermal thermal_sys ac i2c_algo_bit iwlcore cfbcopyarea cfbimgblt btusb mac80211 bluetooth yenta_socket rtc_cmos rsrc_nonstatic output i2c_i801 cfbfillrect battery button i2c_core sg cfg80211 rfkill uvcvideo evdev joydev
The commit you referenced did not alter the way input events are generated so I am not sure what is going on. What kind of hardware is it? Also, is it reproducible with evtest utility on console?
Handled-By : Dmitry Torokhov <dmitry.torokhov@gmail.com>
About the device, dmesg says: Synaptics Touchpad, model: 1, fw: 6.2, id: 0x25a0b1, caps: 0xa04713/0x200000 input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio4/input/input2 I should have mentioned this before, but the touchpad does _not_ have a physical middle mouse button. Pressing both mouse buttons simultaneously acts as a middle mouse button by default. This behavior can be deactivated by setting synclient EmulateMidButtonTime=0. This does not disable the button 2 events generated by the bug, however. I could not reproduce the bug with evtest. It is hard to work with, because it does not flush its output very often, produces a lot of output, and I'm not sure what I am looking for. As for the cause of the bug, maybe with the change the device is advertised as a 3-button mouse so that previously ignored/suppressed events are now coming through. But that is only a wild guess.
It used to advertising itself as 3-button mouse, but not anymore. What does /proc/bus/input/devices show on your box? I am not sure why evtest would not flush on your machine, it seems to be doing this on mine. I would look for: Event: time 1271113350.785485, type 1 (Key), code 273 (RightBtn), value 1 instead of Event: time 1271113376.560063, type 1 (Key), code 272 (LeftBtn), value 1 To confirm that the kernel is generating wrong events. What does lsof /dev/input/event* show on your box BTW?
Ok. This is most likely caused by the multifinger-click feature. The synaptics driver generates a button 2 event if it detects three fingers pressed at the same time. This feature is disabled by default if the touchpad has a middle button, which is why it did not happen before. A simple synclient ClickFinger3=1 deactivates it. Apparently, the multifinger detection is not very accurate, since I triggered it accidentally all the time. I will ask in the Xorg bug report to disable it by default. Since this has nothing to do with the kernel any more, I think we can close this bug report. Thank you for your help. Clemens --- Since I already had it prepared, here is the data you requested. On Mon, Apr 12, 2010 at 11:03:55PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > It used to advertising itself as 3-button mouse, but not anymore. What does > /proc/bus/input/devices show on your box? I: Bus=0011 Vendor=0002 Product=0007 Version=25b1 N: Name="SynPS/2 Synaptics TouchPad" P: Phys=isa0060/serio4/input0 S: Sysfs=/devices/platform/i8042/serio4/input/input2 U: Uniq= H: Handlers=mouse0 event2 B: EV=b B: KEY=6420 30000 0 0 0 0 B: ABS=11000003 With the patch reverted the only difference is this line. B: KEY=6420 70000 0 0 0 0 > What does lsof /dev/input/event* show on your box BTW? COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME acpid 2060 root 3r CHR 13,64 0t0 1686 /dev/input/event0 acpid 2060 root 4r CHR 13,68 0t0 1794 /dev/input/event4 acpid 2060 root 5r CHR 13,69 0t0 1849 /dev/input/event5 acpid 2060 root 6r CHR 13,70 0t0 1801 /dev/input/event6 acpid 2060 root 7r CHR 13,71 0t0 1807 /dev/input/event7 acpid 2060 root 8r CHR 13,72 0t0 1921 /dev/input/event8 acpid 2060 root 9r CHR 13,73 0t0 3054 /dev/input/event9 hald-addo 2519 root 4r CHR 13,73 0t0 3054 /dev/input/event9 hald-addo 2519 root 5w CHR 13,64 0t0 1686 /dev/input/event0 hald-addo 2519 root 6r CHR 13,65 0t0 1674 /dev/input/event1 hald-addo 2519 root 7r CHR 13,70 0t0 1801 /dev/input/event6 hald-addo 2519 root 8r CHR 13,69 0t0 1849 /dev/input/event5 hald-addo 2519 root 9r CHR 13,72 0t0 1921 /dev/input/event8 hald-addo 2519 root 10r CHR 13,71 0t0 1807 /dev/input/event7 hald-addo 2519 root 11r CHR 13,68 0t0 1794 /dev/input/event4 Xorg 13632 root 12u CHR 13,71 0t0 1807 /dev/input/event7 Xorg 13632 root 13u CHR 13,72 0t0 1921 /dev/input/event8 Xorg 13632 root 14u CHR 13,69 0t0 1849 /dev/input/event5 Xorg 13632 root 15u CHR 13,70 0t0 1801 /dev/input/event6 Xorg 13632 root 16u CHR 13,65 0t0 1674 /dev/input/event1 Xorg 13632 root 17u CHR 13,64 0t0 1686 /dev/input/event0 Xorg 13632 root 18u CHR 13,66 0t0 1702 /dev/input/event2 Xorg 13632 root 19u CHR 13,73 0t0 3054 /dev/input/event9
Ok, closing.