Description of problem: Mouse movements cause random 'snapto' to the upper left corner hot spot in Gnome3. This causes the Activities screen to display, interrupting any work in the focused window. Version-Release number of selected component (if applicable): xorg-x11-server-common-1.12.3-1.fc17 (64-bit) xorg-x11-server-Xorg-1.12.3-1.fc17 (64-bit) xorg-x11-server-Xephyr-1.12.3-1.fc17 (64-bit) How reproducible: Always Steps to Reproduce: 1. Activate any window on the Gnome3 desktop 2. move mouse around 3. With in a minute the screen will display the Activities screen. Actual results: screen switches to the Activities screen Expected results: Current screen remains active Additional info: downgraded the xorg-x11-server files to the 1.12.0-2 version and problem was resolved.
I experienced this same behavior, but within the KDE desktop environment. This was on 2 different 64bit virtualbox machines running on 2 different systems. This is on a fully patched Fedora 17 x64. Downgrading the three xorg-x11-server packages listed above to the 1.12.0-2 versions corrected this behavior completely for me on both systems.
*** Bug 856242 has been marked as a duplicate of this bug. ***
Transferring Alpha blocker nomination from #856242. Several people confirmed seeing the bug there, and there are reports on test@ that it's affecting VirtualBox too.
updating to xorg server 1.13.0 doesn't fix this in f18, fwiw.
I submitted the original bug report and I neglected to identify my environment as VirtualBox. The problem first occured in VB 4.1.18, got significantly worse with VB 4.1.20 and remains the same in VB 4.1.22.
I have a feeling the may be related to the special vmware mouse mode of ps/2 mouse emulation, can people who are seeing this in in virtual box please attach their /var/log/Xorg.0.log ?
Hi, Me again, 2 more things: 1) Can you try doing: sudo rpm -e --nodeps xorg-x11-drv-vmmouse, and then restarting Xorg ? 2) Another possible culprit could be a usb-tablet, does the vm have a usb-tablet (see lsusb in the guest) ? Regards, Hans
Created attachment 612060 [details] Xorg.0.log ad 1) Didn't help even after reboot. ad 2) Default VMs in virt-manager have EvTouch tablet assigned. If I remove it and reboot, the issue is still present.
(In reply to comment #8) > Created attachment 612060 [details] > Xorg.0.log > > ad 1) Didn't help even after reboot. > > ad 2) Default VMs in virt-manager have EvTouch tablet assigned. If I remove > it and reboot, the issue is still present. Hi, copy pasting this to "bug 852842", which is the more generic tracking bug for this issue, this one is specifically for people seeing this under virtualbox (at least for now). Also I've more questions, but I'll ask those in bug 852842 too.
Correction the bug number in my last comment should be bug 856242
Hans, I saw this happen either with a uinput device (spice-vdagent) or with usb tablet emulation, but not with imps/2 emulation. I test by running [spice@f18qxlkms ~]$ xinput test 9 | grep =0 motion a[0]=0 a[1]=0 motion a[0]=0 a[1]=0 Alon
As discussed in bug 856242, this seems to happen with both virtualbox & qemu-vnc & qemu-spice, and with both spice-vdagent and usb-tablets within qemu, so I'm pretty sure this really is an xorg bug, also as indicated by comment #0, donwgrading F-17 xorg to the non updates version fixes this, giving more clues that this seems to be an xorg issue.
*** Bug 856250 has been marked as a duplicate of this bug. ***
*** Bug 856252 has been marked as a duplicate of this bug. ***
replying to the other bug here: (In reply to comment #22) > (In reply to comment #21) > > Yes, it occurs with usb-tablet & disabled vdagent, too (in RHEL 6 VM). > > How up2date is this RHEL-6 vm / which xorg-server version does it use ? # rpm -q xorg-x11-server-Xorg xorg-x11-server-Xorg-1.13.0-1.el6.x86_64
(In reply to comment #16) > replying to the other bug here: > > (In reply to comment #22) > > (In reply to comment #21) > > > Yes, it occurs with usb-tablet & disabled vdagent, too (in RHEL 6 VM). > > > > How up2date is this RHEL-6 vm / which xorg-server version does it use ? > > # rpm -q xorg-x11-server-Xorg > xorg-x11-server-Xorg-1.13.0-1.el6.x86_64 Ah yes, so that is newer then the F-17 xorg-x11-server-Xorg-1.12.0 -> 1.12.3 transition when this was first seen, given that it was first seen in an xorg bugfix release it should be easy to find the actual commit, as the bugfix releases have relatively few commits. But thanks for the info, that you're seeing it with that version is just 1 bit more proof that this is caused by xorg.
Discussed at 2012-09-12 blocker review meeting. The clause under which this stands the most chance of being accepted is "Bug hinders execution of required Alpha test plans or dramatically reduces test coverage", but we agreed that Alpha involves so little desktop testing that it doesn't really count, so it's rejected as an Alpha blocker, accepted as NTH (since it's really freaking annoying). There was considerable support for Beta blocker status under the above clause, so re-proposing as Beta blocker too.
Created attachment 612911 [details] Xorg.0.log from F17 in Virtualbox 4.1.22
Created attachment 612912 [details] lsusb output from F17 on virtualbox 4.1.22
Hans, for me this started with a recent F17 system update on 2012-09-11. Looking at my yum log (grepped for xorg), here were my recent xorg updates if that helps: Jul 03 13:59:52 Updated: xorg-x11-server-common-1.12.2-4.fc17.x86_64 Jul 03 13:59:58 Updated: xorg-x11-server-Xorg-1.12.2-4.fc17.x86_64 Jul 03 13:59:59 Updated: xorg-x11-server-Xephyr-1.12.2-4.fc17.x86_64 Aug 02 08:48:06 Updated: xorg-x11-drv-intel-2.20.1-1.fc17.x86_64 Sep 11 11:53:30 Updated: xorg-x11-server-common-1.12.3-1.fc17.x86_64 Sep 11 11:55:49 Updated: xorg-x11-server-Xorg-1.12.3-1.fc17.x86_64 Sep 11 11:56:44 Installed: abrt-addon-xorg-2.0.12-1.fc17.x86_64 Sep 11 11:57:08 Updated: xorg-x11-drv-intel-2.20.6-1.fc17.x86_64 Sep 11 11:57:47 Updated: xorg-x11-server-Xephyr-1.12.3-1.fc17.x86_64
(In reply to comment #8) > Default VMs in virt-manager have EvTouch tablet assigned. If I remove > it and reboot, the issue is still present. This workaround works for me, though. I shut down the VM (an up to date f18) and removed the tablet on the details page of the virtual machine in virt-manager. After booting the VM again the issue was gone.
Please see bug 856242 comment 16: > So the only way how to fix this issue is to remove spice-vdagent AND > remove the tablet. Any other combination breaks it. At least that was my observation.
(In reply to comment #7) > 2) Another possible culprit could be a usb-tablet, does the vm have a > usb-tablet (see lsusb in the guest) ? I have tried it on my machine with up to date F18 and it solves the problem, at least for me.
Sorry - I'm a bit confused. I am on a Win7 host, F17 guest. The F17 guest shows the "VirtualBox USB Tablet" in 'lsusb' output and I have spice-vdagent installed. Uninstalling the package is easy enough of course, but how do I remove the "USB Tablet" that is being seen? I still have the downgraded xorg packages installed to keep everything working but would like to test this other solution as well.
(In reply to comment #23) > (In reply to comment #8) > > > Default VMs in virt-manager have EvTouch tablet assigned. If I remove > > it and reboot, the issue is still present. > > This workaround works for me, though. I shut down the VM (an up to date f18) > and removed the tablet on the details page of the virtual machine in > virt-manager. After booting the VM again the issue was gone. Removing the wacom tablet also didn't solve the issue for me.
I've been failing to reproduce this on the VM's I have here. Can you please record the QEMU's tablet event sequence with evemu-record and attach the output here? I need to figure out how this is triggered, maybe replaying the event sequence triggers the bug here too. More info about how to use evemu is here: http://people.freedesktop.org/~whot/evemu/
update: I've been able to reproduce this, but it's completely random and when it happens, the event sequence gives no hint on anything going wrong. Any hints on how to reproduce this reliably appreciated.
whot: for me it happens reliably simply booting an F18 Alpha live image on an F18 host, in a VM created with default configuration by virt-manager. It happens frequently and unavoidably. It plays hell with some Alpha testing, actually. I can attach my VM definition if it's any help.
Yes, the same for me. But on an F16 host, VM is using qxl/spice w/ mouse+wacom and only mouse (wacom removed). Too me it seems as if there are two mouse pointers in the game (in the VM). A hidden one with a changing offset and the visible one.
Found a possible culprit, scratch build is attached here, please let me know if that fixes it. F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=4503192 F18: http://koji.fedoraproject.org/koji/taskinfo?taskID=4503213
Peter, that fixed the issue for me (running F18 Alpha into a VM hosted in a F17 gust) thanks!
Peter, looks good! I can no longer reproduce the bug after I updated to that xorg build.
Peter - that did the trick for me too. I can no longer reproduce the issue on either of my (separate) F17 vbox guests running on Win7 hosts. Thank you!
(In reply to comment #32) > Found a possible culprit, scratch build is attached here, please let me know > if that fixes it. > > F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=4503192 Tested with F17 vbox guest and seems good, thank you.
xorg-x11-server-1.13.0-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xorg-x11-server-1.13.0-5.fc18
xorg-x11-server-1.12.3-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xorg-x11-server-1.12.3-2.fc17
Package xorg-x11-server-1.12.3-2.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.12.3-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14449/xorg-x11-server-1.12.3-2.fc17 then log in and leave karma (feedback).
xorg-x11-server-1.12.3-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
xorg-x11-server-1.13.0-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Still broken in Rawhide, though (which has 1.12.99.904-2.20120808.fc19). Could someone do a Rawhide build? Thanks.
Rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4549045