Bug 471172 - Upgrade to xorg-x11-drv-vmmouse-12. 6.1-1.fc9 changes mouse clicks on gnome-panel
Upgrade to xorg-x11-drv-vmmouse-12. 6.1-1.fc9 changes mouse clicks on gnome-p...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: EasyFix
: 479185 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-12 01:08 EST by Kam Leo
Modified: 2009-01-08 20:46 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-04 19:11:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xev output (12.00 KB, text/plain)
2008-11-14 02:39 EST, Kam Leo
no flags Details
Xorg log (53.73 KB, text/plain)
2008-11-14 02:44 EST, Kam Leo
no flags Details
xev output for aisleriot solitare. (12.00 KB, text/plain)
2008-11-18 02:53 EST, Kam Leo
no flags Details
xev for Old vmmouse driver (4.00 KB, text/plain)
2008-11-18 02:56 EST, Kam Leo
no flags Details
Button events (268.00 KB, text/plain)
2008-11-18 03:22 EST, Kam Leo
no flags Details
output of lshal (69.27 KB, text/plain)
2008-11-26 08:10 EST, Clive Malcolm
no flags Details
output from xev - mouse clicks (81.82 KB, text/plain)
2008-11-26 08:12 EST, Clive Malcolm
no flags Details
Xorg log file (18.82 KB, text/plain)
2008-11-26 08:12 EST, Clive Malcolm
no flags Details

  None (edit)
Description Kam Leo 2008-11-12 01:08:42 EST
Description of problem: 

Running F9 using VMWare Workstation 5.5.8 and Windows 2000 Professional.

After upgrading from xorg-x11-drv-vmmouse-12.5.0.-1.fc9 to xorg-x11-drv-vmmouse-12.6.1-1.fc9 mouse clicks on the task bar no longer work the same as they did with the previous version. Left-clicking on Applications, Places, or System does not cause a stationary drop-down menu to appear. Left-clicking on the Firefox icon does not launch the web browser. A user must hold down the mouse button in order to view the drop-down menus. Holding down the right-mouse button while clicking on an icon will bring up a dialog to launch the application.

Version-Release number of selected component (if applicable):
xorg-x11-drv-vmmouse-12.6.1-1.fc9.i386

How reproducible:
Every time.

Steps to Reproduce:
1. Run F9 using VMWare Workstation 5.5.8 
2. Upgrade or install xorg-x11-drv-vmmouse to version 12.6.1-1.fc9
3. Log in/start up in gnome desktop
  
Actual results:


Expected results:


Additional info:
Comment 1 Jerry James 2008-11-12 11:28:48 EST
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.
Comment 2 Jerry James 2008-11-12 11:43:48 EST
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.
Comment 3 Matěj Cepl 2008-11-12 21:30:49 EST
So, now it is apparently just a problem with pushing xorg-x11-server package out of testing?
Comment 4 Kam Leo 2008-11-13 14:32:46 EST
(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.
Comment 5 Kam Leo 2008-11-13 15:07:42 EST
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.
Comment 6 Peter Hutterer 2008-11-13 20:34:26 EST
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.
Comment 7 Kam Leo 2008-11-14 02:39:05 EST
Created attachment 323545 [details]
xev output

Here's the xev output. Hope it is of sufficient length.
Comment 8 Kam Leo 2008-11-14 02:44:55 EST
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.
Comment 9 Peter Hutterer 2008-11-17 22:10:06 EST
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.
Comment 10 Kam Leo 2008-11-18 02:53:39 EST
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.
Comment 11 Kam Leo 2008-11-18 02:56:19 EST
Created attachment 323857 [details]
xev for Old vmmouse driver

Output for solitaire game. Notice button events.
Comment 12 Peter Hutterer 2008-11-18 03:09:57 EST
uhm. you actually have to click into the xev window, otherwise the button events get sent to other applications, not to xev.
Comment 13 Kam Leo 2008-11-18 03:22:32 EST
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.
Comment 14 Peter Hutterer 2008-11-18 19:21:43 EST
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.
Comment 15 Kam Leo 2008-11-19 12:59:46 EST
(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.
Comment 16 Peter Hutterer 2008-11-21 01:34:16 EST
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.
Comment 17 Kam Leo 2008-11-22 03:22:40 EST
(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?
Comment 18 Peter Hutterer 2008-11-23 19:55:20 EST
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.
Comment 19 Kam Leo 2008-11-24 13:28:54 EST
(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.
Comment 20 Peter Hutterer 2008-11-26 00:48:47 EST
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
Comment 21 Clive Malcolm 2008-11-26 08:10:31 EST
Created attachment 324705 [details]
output of lshal
Comment 22 Clive Malcolm 2008-11-26 08:12:05 EST
Created attachment 324707 [details]
output from xev - mouse clicks
Comment 23 Clive Malcolm 2008-11-26 08:12:53 EST
Created attachment 324708 [details]
Xorg log file
Comment 24 Clive Malcolm 2008-11-26 08:20:14 EST
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.
Comment 25 Kam Leo 2008-11-26 22:18:40 EST
(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.
Comment 26 Kam Leo 2008-11-27 01:42:11 EST
(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.
Comment 27 Peter Hutterer 2008-12-02 17:59:02 EST
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?
Comment 28 Kam Leo 2008-12-03 22:13:05 EST
(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.
Comment 29 Clive Malcolm 2008-12-04 03:04:27 EST
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.
Comment 30 Matěj Cepl 2008-12-04 19:11:15 EST
Thanks for letting us know. Closing as NOTABUG but noticing that this should just work.
Comment 31 Kam Leo 2008-12-06 12:23:40 EST
(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.
Comment 32 Peter Hutterer 2009-01-08 20:44:25 EST
*** Bug 479185 has been marked as a duplicate of this bug. ***
Comment 33 Peter Hutterer 2009-01-08 20:46:02 EST
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.

Note You need to log in before you can comment on or make changes to this bug.