Bug 471172

The problem is that a single mouse click is generating TWO button down events.  Try launching xev and clicking in it.  This makes the vmmouse driver pretty much unusable for me.  I've had to drop back to the generic "mouse" driver.

This happens with the synaptics mouse buttons as well as an external USB mouse.

It looks like an update was made to xorg-x11-server at the same time as the change to xorg-x11-drv-vmmouse, but only the vmmouse driver got pushed to stable.  That's bad.  I grabbed xorg-x11-server-1.5.2-3.fc9 from the testing repo, and now the problem is fixed.  Why didn't these two get pushed together?  Now everybody running VMWare has a broken mouse until the server update gets pushed.

So, now it is apparently just a problem with pushing xorg-x11-server package out of testing?

(In reply to comment #3)
> So, now it is apparently just a problem with pushing xorg-x11-server package
> out of testing?

Downloading and installing xorg-x11-server-common-1.5.2-3.fc9.i386 and xorg-x11-server-Xorg-1.5.2-3.fc9.i386 from testing did not fix the problem. Mouse clicks are still screwed up.

Users with different version of VMWare Workstation may see different behavior. Ed Greshko uses VMMware Workstaton 6.5 on Linux and did not have any problems with his F9 setup after upgrading xorg-x11-drv-vmmouse.

Can you please run xev and attach the output of the clicks here. This should give us an indication as to what exactly is happending.

Also, please attach your Xorg.log.

Created attachment 323545 [details]
xev output

Here's the xev output. Hope it is of sufficient length.

Created attachment 323546 [details]
Xorg log

Here's the Xorg log. Last change should show me reverting back to original vmmouse driver because it's nearly impossible to use bugzilla without a working mouse.

there are no button events at all in the xev log. Do the buttons work or don't the work at all? From comment #1 I gather they do work in some cases. Can you please attach an xev log that includes button events? Thanks.

Created attachment 323856 [details]
xev output for aisleriot solitare.

xev-2.txt is the output for an entire game of solitare. Notice no button events.

Created attachment 323857 [details]
xev for Old vmmouse driver

Output for solitaire game. Notice button events.

uhm. you actually have to click into the xev window, otherwise the button events get sent to other applications, not to xev.

Created attachment 323859 [details]
Button events

Sorry, I was observing button events when xev output was not redirected to a file. Realized that I needed to maximize the "Event Test" window and click within that window after I sent the files. This file should have button events captured.

You're getting duplicate events because the server is picking up /dev/input/mice and the actual device through the HAL/evdev mechanisms. Usually this isn't a problem since evdev puts a grab on the kernel device and thus prevents these duplicate events (in F9 anyway, F10 works different here).

I don't know why that doesn't work in your case, but adding Option "AutoAddDevices" "off" to your ServerLayout should fix the symptoms.

(In reply to comment #14)
> You're getting duplicate events because the server is picking up
> /dev/input/mice and the actual device through the HAL/evdev mechanisms. Usually
> this isn't a problem since evdev puts a grab on the kernel device and thus
> prevents these duplicate events (in F9 anyway, F10 works different here).
> 
> I don't know why that doesn't work in your case, but adding Option
> "AutoAddDevices" "off" to your ServerLayout should fix the symptoms.

1. Adding Option "AutoAddDevices" "off" to ServerLayout section of xorg.conf fixes the problem.

2. I'm using F9 so evdev is not doing what you think it should be doing.

that'll probably be hard to do, but if you can, can you please download http://people.freedesktop.org/~whot/evtest.c, compile it (gcc -o evtest evtest.c) and run it as sudo ./evtest /dev/input/eventX, where eventX is your keyboard device (check /proc/bus/input/devices)

If the evdev driver actually puts a grab on the device*, then evtest should complain about not being able to grab it.

* evdev should complain about it if it can't grab it, so I'm a bit baffled here.

(In reply to comment #16)
> that'll probably be hard to do, but if you can, can you please download
> http://people.freedesktop.org/~whot/evtest.c, compile it (gcc -o evtest
> evtest.c) and run it as sudo ./evtest /dev/input/eventX, where eventX is your
> keyboard device (check /proc/bus/input/devices)
> 
> If the evdev driver actually puts a grab on the device*, then evtest should
> complain about not being able to grab it.
> 
> * evdev should complain about it if it can't grab it, so I'm a bit baffled
> here.

Compiled and ran evtest. Ran evtest on /dev/input/event2 (keyboard) and /dev/input/event3 (mouse). No complaint from evdev. Ran evtest with the patched xorg.conf file. Should I remove the patch and run evtest again?

yes, if you have AutoAddDevices "off", evdev doesn't activate so the test is a noop.

Just remove the line, restart the server and then run evtest. Thanks.

(In reply to comment #18)
> yes, if you have AutoAddDevices "off", evdev doesn't activate so the test is a
> noop.
> 
> Just remove the line, restart the server and then run evtest. Thanks.

Commented out AutoAddDevices line in xorg.conf, rebooted, ran evtest, and got similar results from evtest for event2 and event3. Detected no complaints from evdev.

Oh, my fault. The evtest I had on there didn't do the grab. Please try again with the updated source file

http://people.freedesktop.org/~whot/evtest.c

Created attachment 324705 [details]
output of lshal

Created attachment 324707 [details]
output from xev - mouse clicks

Created attachment 324708 [details]
Xorg log file

Hi, details of my setup.

I am running Windows Vista Home Premium as the Host OS

VMware Player 2.0.5 

Fedora9 with current Packagekit updates as the guest OS.

I am having the same problems as mentioned in the description.

I have added 3 files as requested, let me know if you would like me to do any more testing.

(In reply to comment #20)
> Oh, my fault. The evtest I had on there didn't do the grab. Please try again
> with the updated source file
> 
> http://people.freedesktop.org/~whot/evtest.c

Ran the test with the file referenced above. Still no complaints from evdev. Checked the file linked above with the previous one; no difference. Perhaps you can link to the new version of evtest.c.  Please add a revision number to the new file for differentiation.

(In reply to comment #25)
> (In reply to comment #20)
> > Oh, my fault. The evtest I had on there didn't do the grab. Please try again
> > with the updated source file
> > 
> > http://people.freedesktop.org/~whot/evtest.c
> 
> Ran the test with the file referenced above. Still no complaints from evdev.
> Checked the file linked above with the previous one; no difference. Perhaps you
> can link to the new version of evtest.c.  Please add a revision number to the
> new file for differentiation.

Arrgh! Did a double-check between the file downloaded using Firefox browser and wget and found that there actually was a difference. Unfortunately Firefox downloader does not care and just created a copy of the original (first) file and appended "(2)" to the name. Any way, recompiled evtest.c and noticed "Grab succeeded, ungrabbing." in the output for /dev/input/event2 and /dev/input/event3.  Still nothing from evdev.

What a mess. Ok, so here's about what happens:

The server defaults to AllowEmptyInput "off" because of a patch we use in F9 to avoid all the keyboard issues that plagued F10 when it was still rawhide.
AEI off means that the server forces default input devices if none are present in the config. For the mouse pointer, this means /dev/input/mice.

AutoAddDevices "on" means the server adds devices at runtime, including the vmmouse since 12.6. Because we now add the same device again, we get duplicate events. AAD off simply means the vmmouse driver doesn't get added, hence the issue is fixed.

The better fix is to set AllowEmptyInput "on". This way, the default mouse section isn't added and that should fix the problem too. HOWEVER, if you do so, you MUST HAVE a keyboard section in your xorg.conf, otherwise you will end up with no keyboard (thanks to the patch mentioned above).

So again, make sure you have a keyboard section in your xorg.conf, then set Option AllowEmptyInput "on" in the ServerLayout or ServerFlags and this should fix the issue. Can you confirm this please?

(In reply to comment #27)
> What a mess. Ok, so here's about what happens:
> 
> The server defaults to AllowEmptyInput "off" because of a patch we use in F9 to
> avoid all the keyboard issues that plagued F10 when it was still rawhide.
> AEI off means that the server forces default input devices if none are present
> in the config. For the mouse pointer, this means /dev/input/mice.
> 
> AutoAddDevices "on" means the server adds devices at runtime, including the
> vmmouse since 12.6. Because we now add the same device again, we get duplicate
> events. AAD off simply means the vmmouse driver doesn't get added, hence the
> issue is fixed.
> 
> The better fix is to set AllowEmptyInput "on". This way, the default mouse
> section isn't added and that should fix the problem too. HOWEVER, if you do so,
> you MUST HAVE a keyboard section in your xorg.conf, otherwise you will end up
> with no keyboard (thanks to the patch mentioned above).
> 
> So again, make sure you have a keyboard section in your xorg.conf, then set
> Option AllowEmptyInput "on" in the ServerLayout or ServerFlags and this should
> fix the issue. Can you confirm this please?

Removed 'Opton AutoAddDevices "on"', added 'Option AllowEnptyInput "on"' to ServerLayout section of xorg.conf, rebooted, and verified fix works.

I have just added

        Option          "AllowEmptyInput" "on"

to the ServerLayout Section section, already have an InputDevice Section with a Keyboard0.

Rebooted

Mouse is working correctly

I confirm the fix works for me.

Thanks for everyones help in identifying this issue and coming up with a fix.

Thanks for letting us know. Closing as NOTABUG but noticing that this should just work.

(In reply to comment #30)
> Thanks for letting us know. Closing as NOTABUG but noticing that this should
> just work.

From a QA viewpoint "NOTABUG" is so wrong! You admit that there is problem and a solution. Change status to "WONTFIX", "CANTFIX", or "NEXTRELEASE". 

Hopefully, someone will fix the install script to correctly configure xorg.conf.

*** Bug 479185 has been marked as a duplicate of this bug. ***

Updating bug status to NEXTRELEASE. This is a known bug for F9 and we don't have a better workaround than the Option AllowEmptyInput on in the ServerLayout of the xorg.conf. See more details in Comment #27.

This issue has been fixed in F10.