Created attachment 1193340 [details] cursor position and movement wrong Description of problem: Watch the funny video attached. Not only the cursor position is wrong, but also the movement translates to different directions! (I move left and right, it moves up and down). I can't reproduce this on Fedora-Workstation-Live-x86_64-25-20160822.n.0.iso, but I can reproduce it on a fully updated installed F25 system in a VM. Petr Schindler saw the same problem on his computer (also in a VM). Switching back to X11 fixes the issue. Version-Release number of selected component (if applicable): guest system: clutter-1.26.0-1.fc25.x86_64 clutter-gst2-2.0.18-1.fc25.x86_64 clutter-gst3-3.0.18-1.fc25.x86_64 clutter-gtk-1.8.0-1.fc25.x86_64 gnome-session-wayland-session-3.21.90-1.fc25.x86_64 gnome-shell-3.21.90.1-1.fc25.x86_64 ibus-wayland-1.5.14-1.fc25.x86_64 kernel-4.8.0-0.rc1.git0.1.fc25.x86_64 libwayland-client-1.11.91-1.fc25.x86_64 libwayland-cursor-1.11.91-1.fc25.x86_64 libwayland-server-1.11.91-1.fc25.x86_64 mesa-libwayland-egl-12.0.1-2.fc25.x86_64 mutter-3.21.90-2.fc25.x86_64 spice-glib-0.32-2.fc25.x86_64 spice-gtk3-0.32-2.fc25.x86_64 spice-server-0.13.2-1.fc25.x86_64 spice-vdagent-0.16.0-3.fc24.x86_64 xorg-x11-drv-qxl-0.1.4-8.fc25.x86_64 xorg-x11-server-Xwayland-1.18.4-2.fc25.x86_64 host system: libvirt-1.3.3.2-1.fc24.x86_64 libvirt-glib-0.2.3-2.fc24.x86_64 libvirt-python-1.3.3-3.fc24.x86_64 qemu-common-2.6.1-1.fc24.x86_64 qemu-guest-agent-2.6.1-1.fc24.x86_64 qemu-img-2.6.1-1.fc24.x86_64 qemu-kvm-2.6.1-1.fc24.x86_64 qemu-system-x86-2.6.1-1.fc24.x86_64 spice-glib-0.32-2.fc24.x86_64 spice-gtk3-0.32-2.fc24.x86_64 spice-server-0.12.8-1.fc24.x86_64 spice-vdagent-0.16.0-3.fc24.x86_64 virt-manager-1.4.0-3.fc24.noarch virt-manager-common-1.4.0-3.fc24.noarch xorg-x11-drv-qxl-0.1.4-7.fc24.x86_64 How reproducible: always, in my VM Steps to Reproduce: 1. install F25 in a VM (in my case spice+qxl, libvirt, virt-manager) 2. fully update it 3. boot it and see cursor misbehaving
Proposing as a blocker: "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments. " https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria#Required_applications We will need to figure out whether this is caused by some package in updates-testing, or whether this is already pushed stable.
So, I narrowed the culprit here: works: gnome-shell-3.21.4-1.fc25.x86_64 mutter-3.21.4-1.fc25.x86_64 doesn't work: gnome-shell-3.21.90.1-1.fc25.x86_64 mutter-3.21.90-2.fc25.x86_64 The affected versions are not stable, i.e. this does not affect Alpha composes and clean installs. But it will break users workstation immediately after first update (because updates-testing is enabled). Therefore I propose this as a 0-day blocker - this either has to be unpushed or fixed at go/no-go call, otherwise we would slip.
Further narrowing down shows this is a mutter problem.
Turns out this doesn't seem to affect bare metal (at least in my case), only VMs, so this is probably more fit for a Beta blocker (according to https://fedoraproject.org/wiki/Fedora_25_Beta_Release_Criteria#Guest_on_current_stable_release , even though this is not explicitly listed there).
this is what's breaking openQA F25 workstation network install tests at present - they get the broken gnome-shell/mutter from updates-testing and then can't make it through initial-setup due to this bug. obviously, it also breaks all GNOME tests for Rawhide from any image.
Carlos, Jonas, any idea what might have caused this? Looks like a .90 regression in mutter.
I haven't investigated this further yet. 3.21.4 -> 3.21.90 was quite big and did various changes to the input parts of things (e.g. tablet v2 support, virtual input device support). Will either need to bisect, or simply debug to see where things go wrong.
we would appreciate if you could look into this promptly, because it causes several of our automated tests to fail in a way we can't work around. so long as this bug exists, any *other* issues that exist 'behind' it can't be caught.
I can reproduce the issue on a VM I sat up. The strange thing is that if I run mutter/gnome-shell/gnome-shell-gdm-mode from a VT the symptom doesn't show up. One thing I noticed is that if I click the VM UI, on the mutter/gnome-shell instances that doesn't have broken input, virt-manager will "grab" the input and I have to press Ctrl-Alt to release it. On the tty1 gdm gnome-shell session with the broken input, nothing seems to respond to any clicks, i.e. I don't need to Ctrl-Alt away the input grab. What controls the availability of this "grabbing"? Could it possibly mess with input events some how?
I'm not sure how exactly input grabbing works (the best person to ask is probably Cole Robinson), but if you remove Tablet and Spice channel from your VM configuration, you can force it to go to "always grab input" mode. I tested it and this bug really does not occur in that case. So yeah, it can very possibly interfere somehow (but it still worked with older mutter).
I bisected this, and while the result seems very odd, it seems the commit that introduced the issue is this one: commit 3c8b1462bc9380da5111230eceec7215d70cef15 Author: Carlos Garnacho <carlosg> Date: Mon Jul 11 18:39:32 2016 +0200 clutter: Make ClutterVirtualInputDevice public This includes adding documentation and introspection annotations, and marking the functions as extern. https://bugzilla.gnome.org/show_bug.cgi?id=765009
Hey Carlos, could you help out with this? Thanks!
It could also be something else, that is stopped from being executed because of the gnome-shell javascript code doesn't successfully continue due to not having the available functions.
That sounds plausible, yes. Might be worth bisecting with an older gnome-shell, such as http://koji.fedoraproject.org/koji/buildinfo?buildID=784305 if you are using F25 packages. Also, Carlos is on PTO this week, unsetting the needinfo as he's not around.
(In reply to Kalev Lember from comment #14) > That sounds plausible, yes. Might be worth bisecting with an older > gnome-shell, such as > http://koji.fedoraproject.org/koji/buildinfo?buildID=784305 if you are using > F25 packages. I built my own gnome-shell 3.21.4 gnome-shell and just installed in /usr, and have been bisecting. It currently looks like its some of other refactorizations that cause the issue. I'll post here when the bisect is done.
New bisect led me to myself: commit 94016f725700b235af9f3c5364d2e7e93d917270 Author: Jonas Ådahl <jadahl> Date: Fri Jun 17 17:42:16 2016 -0400 clutter/evdev: Move keyboard and pointer notification into seat We notify per seat; so lets move the logic there. Touch and tablets to follow later. https://bugzilla.gnome.org/show_bug.cgi?id=765009 and I have a fix that. Upstream bug with attached patch: https://bugzilla.gnome.org/show_bug.cgi?id=770557
Awesome, thanks Jonas!
mutter-3.21.90-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-dd69d33a8b
*** Bug 1369469 has been marked as a duplicate of this bug. ***
Discussed during the 2016-08-29 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made as it clearly violates the following Beta criteria: "The release must be able host virtual guest instances of the same release." combined with multiple desktop criteria [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-08-29/f25-blocker-review.2016-08-29-16.00.txt
tested fix, looks good to me. if anyone else can confirm and add karma that'd be great.
FWIW, the patch didn't make it for 3.21.91, so it has to be carried until the next one.
mutter-3.21.90-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-dd69d33a8b
mutter-3.21.90-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1370938 has been marked as a duplicate of this bug. ***