Description of problem: I rarely run into situations where most or all applications don't seem to get mouse input events any more. They still react to keyboard events. Gnome-shell still works fine handling my mouse events for its own UI. Switching to a tty and back makes this problem go away. Version-Release number of selected component (if applicable): libwayland-client-1.10.0-1.fc24.x86_64 xorg-x11-server-Xwayland-1.18.3-6.fc24.x86_64 mutter-3.20.3-1.fc24.x86_64 gnome-shell-3.20.3-3.fc24.x86_64 gtk3-3.20.6-1.fc24.x86_64 libinput-1.4.0-1.fc24.x86_64 How reproducible: rarely, unknown how to do this What I do: click into an application: Buttons, menus, text fields, sliders, … Actual results: Nothing happens. All (or most?) applications don't get events or ignore them Expected results: Applications should get and handle mouse input. Additional info: Workaround: Switch to any tty and back. You don't need to login. still unclear, I'll add this info once I can. If you can contribute this info, please do so: * does it really affect all applications? * I know I can use https://fedoraproject.org/wiki/How_to_debug_Wayland_problems to hunt down this issue, but I didn't have the chance to do it yet. Still I wanted to report this bug because it might be important and affect other people.
See also bug #1358889, which is mostly the same but with mouse events working and keyboard events partially broken. (In reply to Christian Stadelmann from comment #0) > Additional info: > Workaround: Switch to any tty and back. You don't need to login. To be more precise: Ctrl+Alt+Fn to tty and back is enough to make this bug go away.
I just ran into this bug again. This time I had the chance to start a terminal and run `WAYLAND_DEBUG=1 nautilus` from it. Output shows that the application (nautilus in this case) doesn't get any mouse input at all, so I'm pretty sure this is an issue in the gnome-shell process, probably in mutter.
I'm beginning to think that this is the cause for me when my mouse stops working: Jul 24 20:29:03 mobile-linux org.gnome.Shell.desktop[1702]: (gnome-shell:1702): mutter-CRITICAL **: Failed to open pipe: Too many open files
(In reply to Chris McCabe from comment #3) > Jul 24 20:29:03 mobile-linux org.gnome.Shell.desktop[1702]: > (gnome-shell:1702): mutter-CRITICAL **: Failed to open pipe: Too many open > files That's interesting, I'm seeing this message on my logs quite often lately. `ulimit -a` shows it is limited to 1024 files. I'll raise the limit and look whether this bug goes away. Anyway, I think there is something wrong when my desktop session has 1024 files open, isn't that a bit too much? Processes with most opened files¹: * gnome-shell: about 500; 286 in /usr, 40 in /run, 13 in /dev, 63 times drm * firefox * evolution * … ¹ numbers from `$ watch 'lsof -u username -n -P | awk '\''{print $2}'\'' | sort | uniq -c | sort -n -r'`, some files are counted twice, even per process.
(In reply to Christian Stadelmann from comment #4) I was trying to raise the open files limit, but I can't figure out how to do it. I modified /etc/security/limits.conf but it only affects root. Regular users are stuck at a hard limit of 4096. There must be something overriding it somewhere but I can't find it.
Please note this comment line in /etc/security/limits.conf: > Also note that configuration files in /etc/security/limits.d directory, which are read in alphabetical order, override the settings in this file in case the domain is the same or more specific. > That means for example that setting a limit for wildcard domain here can be overriden with a wildcard setting in a config file in the subdirectory, but a user specific setting here can be overriden only with a user specific setting in the subdirectory. And have you tried rebooting your system?
(In reply to Christian Stadelmann from comment #6) There are no files in /etc/security/limits.d and I have rebooted. After further investigation, I found that some processes, including gnome-shell, are getting the higher limits that I set, but most are stuck at 1024/4096 max open files, including gnome-terminal-server and dbus-daemon.
Hm, I'm seeing the same. Don't know what's going on here.
I'm seeing this bug (mouse events don't get to applications) on Fedora 25 with Gnome 3.22.1 Affected software versions: gtk3-3.22.2-1.fc25.x86_64 glib2-2.50.1-1.fc25.x86_64 mutter-3.22.1-5.fc25.x86_64 gnome-shell-3.22.1-2.fc25.x86_64 libinput-1.5.0-1.fc25.x86_64 libwayland-client-1.12.0-1.fc25.x86_64 (In reply to Chris McCabe from comment #7) > (In reply to Christian Stadelmann from comment #6) > There are no files in /etc/security/limits.d and I have rebooted. After > further investigation, I found that some processes, including gnome-shell, > are getting the higher limits that I set, but most are stuck at 1024/4096 > max open files, including > gnome-terminal-server and dbus-daemon. By the way, the ulimit bug is somewhere else: https://bugzilla.redhat.com/show_bug.cgi?id=1364332
I can reproduce that easily on F25 with a wayland session and it makes wayland unusuable. All XWayland applications will not react to mouse events anymore, native wayland applications continue to work fine.
I just updated my work machine to F25 today and am seeing the same issue. I switched back to Xorg and the problems disappear. It affected Xbindkeys, Firefox, Chrome, Gnome Terminal and Synergy. It may have affected more, but those are the ones that affected my work productivity.
Seeing the same problem on F25. Switching to tty and back fixes it until it happens again. Saw this affecting xterm, evolution, firefox and other applications
I'm running into this problem as well, and I'm a bit frustrated that this bug has been open for over six months with no responses from anyone that actually works on Wayland. It is definitely only happening in Wayland. It also looks like it only affects XWayland apps, as J. Haas said above. I have no vtys configured so I can't use that workaround...the only way to get clicks back is to log out and in. What can I do to debug? I want to keep using Wayland but this is a serious showstopper.
I neglected to share local info. I'm on F25 running wayland, with all latest updates as of today Feb 14 2017.
Hey, same issue here F25 latest... Another workaround that is not listed yet is just close all x11 windows then reopen what you need. At least for me this fixes the problem temporary.
Happens about once in 6 hours of operations to me. I am seeing this bug in all types of applications. (In reply to Dietrich from comment #15) > Another workaround that is not listed yet is just close all x11 windows then > reopen what you need. At least for me this fixes the problem temporary. Seems like XWayland catches the input and doesn't release it again.
Could be an x11 client grabbing the pointer, that would affect only X11 applications and not Wayland native ones, and would prevent any pointer input to x11 clients. Any particular application and/or use pattern that would exhibit that behavior?
I would not describe this as rare. It happens regularly when (in my case) switching from workplaces that are used for development e.g. netbeans and terminal and into a workplace running firefox. I would say roughly 1 in 5 switches. Other usage does not seem to suffer. Remedy is as above Cntrl-Alt F3, Cntrl-Alt F1 and login
(In reply to Olivier Fourdan from comment #17) > Any particular application and/or use pattern that would exhibit that > behavior? No particular applications, as far as I've tested any XWayland application is affected. I am not sure (and will report if I am) whether pure Wayland apps are affected. No particular pattern. There is a similar bug for keyboard input only, I've seen less often: https://bugzilla.redhat.com/show_bug.cgi?id=1358889
I think it never happened for me when neither firefox nor thunderbird was open - but then again there is hardly any time that I do not have those open.
Oh and usually some KDE-Apps are open when it happens Full list: kile kbibtex firefox thunderbird gnome-terminal
FWIW, it looks like the same as the upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=763246
Can someone confirm if the upstream bug fix fixes this?
(In reply to Matthew Miller from comment #23) > Can someone confirm if the upstream bug fix fixes this? Those patches for mutter have been backported to gnome-3.22 branch upstream but have not been part of a mutter 3.22.x update yet, so they are not in f25 either. FWIW, I ran a scratch build with the 4 relevant patches applied to mutter 3.22.3 for those who'd be willing to test on f25: https://koji.fedoraproject.org/koji/taskinfo?taskID=18522460 Of course, this requires restarting the Wayland session (mutter/gnome-shell being the Wayland compositor) As usual, being a scratch build, those packages will self destruct after a short period of time :)
Since I do not have a reproducer, I will test the scratch build and wait for the bug to happen again. Just ask again in about 2 weeks.
I can confirm the upstream patch partially fixes the behavior described in https://bugzilla.gnome.org/show_bug.cgi?id=763246#c29, but it introduces a new bug (drag and drop broken completely, see https://bugzilla.gnome.org/show_bug.cgi?id=763246#c48).
(In reply to Christian Stadelmann from comment #26) > [...] but it introduces a new bug (drag and drop broken completely, see > https://bugzilla.gnome.org/show_bug.cgi?id=763246#c48). "drag and drop broken completely" is not an accurate description, it works, see my reply https://bugzilla.gnome.org/show_bug.cgi?id=763246#c49
During the "Prioritized bugs and issues" meeting we have postponed evaluation of this bug for the next meeting, to collect more thought on this.
Removing the request for the Prioritized bug as there is already an upstream patch. https://meetbot.fedoraproject.org/fedora-meeting/2017-04-19/fedora_prioritized_bugs_and_issues.2017-04-19-14.01.html
Using Fedora 25 fully updated as of 17/06/2017, GNOME. For me the culprit seems to be VirtualBox. Sometimes after clicking VB guest window I loose the mouse for 50% of the apps which I believe are the ones using XWayland (Firefox, Thunderbird, Antimicro), while GNOME Terminal, Software, RythmBox still react as expected. Just found this bug report, and have not tried yet to switch to a console. My previous solution was to close the guest (Win 10) saving the state and restarting it.
Happened to me just like in comment #30. Fedora 26, GNOME, VirtualBox. Closing the virtual machine fixed the issue.
In reply to Andrea from comment #30 and Michał Wróbel from comment #31: Yours are separate issues so you might want to open a separate bug report, probably against VirtualBox. The upstream bug report has been closed as fixed for a while and the fix has landed in Fedora 26 since. Based on this, I am closing this bug report.