Bug 1080015 - Mouse unusable under Wayland
Mouse unusable under Wayland
Status: RESOLVED FIXED
: 1083648 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: GNOME
Current
x86-64 openSUSE Factory
: P5 - None : Major with 1 vote (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-02-08 09:18 UTC by Alexandre Singh
Modified: 2018-03-05 22:46 UTC (History)
11 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Singh 2018-02-08 09:18:19 UTC
Hello, I upgraded two days ago (snapshots 20180203 and 20180205 cumulated), after reboot at GDM login screen or inside GNOME session under Wayland I can only move cursor, I can't click and hovering an element doesn't do anything.

I'm aware of Mesa update plus cache cleaning (20180207) to fix SDDM white screen issue but it doesn't solve my problem.

Of course I tried with other mice.

I don't have this issue under Xorg.

I see that snapshot 20180203 provided a Mutter update bringing a lot of input changes, mostly about "touch" input, but could be related anyway.

The weird thing is that I don't see anyone reporting this issue in factory mailing-list or Reddit for the moment, while SDDM issue was very discussed.
Comment 1 Neil Rickert 2018-02-08 23:41:37 UTC
I can confirm this.

This was with Tumbleweed on a KVM virtual machine.  I haven't yet applied this update to a bare metal system.

So it booted to "gdm".  The mouse moved but could not click anything.

My temporary workaround:  I used CTRL-ALT-F1 to get to a command line, and logged in there as root.  Then I use "update-alternatives" to switch to "lightdm".

Everything seems fine with "lightdm", presumably because it uses Xorg and does not use Wayland.  Login to Xorg sessions seems fine.  I have not tried login to a Wayland session, because that never worked with "lightdm".
Comment 2 Neil Rickert 2018-02-08 23:46:46 UTC
I'll mention this while I'm about it, though it probably needs a new bug report.

When running "update-alternatives" to change the display-manager, it showed "gdm" as the automatic choice, and anything else as a manual choice.  A few days ago, I was seeing "sddm" as the automatic choice.  I didn't think this was supposed to change.
Comment 3 Alexandre Singh 2018-02-09 01:44:03 UTC
@Neil: thank you for confirming this.

By the way, instead of installing LightDM,
you can force GDM to use Xorg backend:
-> open as root with nano or other "/etc/gdm/custom.conf"
--> uncomment by removing "#" this line "#WaylandEnable=false"
Comment 4 Neil Rickert 2018-02-09 03:46:00 UTC
I already had "lightdm" installed, so that was the easiest choice.

I have since update a bare metal machine.  And no problem there.

Back to the VM where I had the problem, I have now updated to 20180207.  Unfortunately the problem is still there.
Comment 5 Neil Rickert 2018-02-11 16:47:17 UTC
Some more on this.

Note that this is still using a KVM virtual machine.  I am not having any problems on real hardware (with Intel graphics).

Today, I switched to "sddm".  I think that still runs under X.

Using "sddm", I was able to login to a Wayland-plasma session.  And the mouse is working fine there.

I then tried to login to a Wayland-gnome session.  And the mouse is dead in Wayland Gnome.  The Gnome session otherwise works, except it is hard to do anything without a mouse.

So this looks to be a problem only for Gnome, and not for everything Wayland.
Comment 6 Alexandre Singh 2018-02-11 17:25:22 UTC
Thanks. Yeah it's why I think (but can't be sure) that it's related to latest Mutter update (see 1st post)... My build is full AMD by the way.
Comment 7 Neil Rickert 2018-02-11 19:37:25 UTC
I checked mutter.

I happened to have:
libmutter-1-0-3.26.2+20171231.0bd1d7cf0-1.1.x86_64.rpm
mutter-3.26.2+20171231.0bd1d7cf0-1.1.x86_64.rpm
mutter-data-3.26.2+20171231.0bd1d7cf0-1.1.x86_64.rpm
mutter-lang-3.26.2+20171231.0bd1d7cf0-1.1.noarch.rpm

on my NFS server.  I have Tumbleweed set to keep packages.  I delete them after a while, but I had not yet deleted those.

So I installed them.  It required me to uninstall bundle-lang-gnome-en

I retested.  The mouse is still not recognized by "gdm".  So I guess it wasn't "mutter".  I have since reinstalled the updated (20180127) mutter packages.
Comment 8 Deni Jakac 2018-02-11 21:12:07 UTC
I have the same problem with gnome under wayland. With an amd laptop A8 trinity.
I tested with the terminal the tap-to-click and it works. But gnome doesn't recognise the mouse/touchpad clicks. I can move the coursor.
For now I'll use IceWM.
Comment 9 Olaf Hering 2018-02-23 16:04:38 UTC
Still happens today, Dell OptiPlex 980.
Comment 10 QK ZHU 2018-02-27 04:11:14 UTC
openQA also spotted this bug on SLED, and it might be a regression issue due to the version bump of Mesa.

Downgrade Mesa, Mesa-dri, Mesa-gallium, Mesa-libEGL1, Mesa-libGL1, Mesa-libglapi0, Mesa-libva to version 17.3.3-15.4 could workaround the issue on SLE.
Comment 11 Stefan Dirsch 2018-02-27 10:48:03 UTC
Ok. If it's really Mesa and only occurs with virtio VGA emulation. Is this still reproducable after removing /usr/lib64/dri/virtio_gpu_dri.so? Given that we still run on Wayland afterwards ...
Comment 12 Marcus Rückert 2018-02-27 10:55:19 UTC
Stefan: I have that problem on real hardware. And it is super annoying.
Comment 13 Neil Rickert 2018-02-27 15:13:39 UTC
>Is this still reproducable after removing /usr/lib64/dri/virtio_gpu_dri.so?

I'm only seeing the issue with "virtio".  So I tried this.  It did not help.  I have since restored the file.

I'm doubting the suggested Mesa connection.  If that were the issue, I would expect it to affect KDE-plasma as well as Gnome.  But Wayland-plasma is working fine (or, at least, the mouse is working fine).  I only see this problem with Wayland-Gnome.
Comment 14 Michal Srb 2018-02-28 07:58:53 UTC
This is a bug in gnome-shell/mutter triggered by new feature in Mesa:
https://gitlab.gnome.org/GNOME/mutter/issues/2
https://bugs.freedesktop.org/show_bug.cgi?id=104808
Comment 15 Neil Rickert 2018-03-02 02:13:16 UTC
This problem is now showing up in Leap 15.0 Build 147.1.  I am seeing it using a KVM virtual machine.
Comment 16 Yifan Jiang 2018-03-02 02:26:21 UTC
(In reply to Neil Rickert from comment #15)
> This problem is now showing up in Leap 15.0 Build 147.1.  I am seeing it
> using a KVM virtual machine.

The fix was accepted, while we might need to wait for the next Leap build before mutter get updated.
Comment 17 Dominique Leuenberger 2018-03-02 09:46:33 UTC
*** Bug 1083648 has been marked as a duplicate of this bug. ***
Comment 18 Joerg Roedel 2018-03-02 09:52:44 UTC
(In reply to Neil Rickert from comment #15)
> This problem is now showing up in Leap 15.0 Build 147.1.  I am seeing it
> using a KVM virtual machine.

I am also seeing this on real hardware.
Comment 19 Neil Rickert 2018-03-03 01:34:40 UTC
This is now fixed in Tumbleweed snapshot 20180301

Or, at least, it is fixed for me using a KVM virtual machine.
Thanks.
Comment 20 Joerg Roedel 2018-03-05 08:45:32 UTC
I am still seeing this problem with latest Leap 15.0 on real hardware with a AMD Radeon GPU.
Comment 21 Michal Srb 2018-03-05 09:35:37 UTC
(In reply to Joerg Roedel from comment #20)
> I am still seeing this problem with latest Leap 15.0 on real hardware with a
> AMD Radeon GPU.

The mutter in newest Leap 15.0 does not have the fix yet.
Comment 22 Alexandre Singh 2018-03-05 22:46:27 UTC
Hello, I confirm that this issue disappeared on Tumbleweed.

I change the status to "fixed" since patches are coming to Leap 15 too.

Thanks!