Mouse cursor can no longer click on anything or change focus

[e00E]

$ sway --version
sway version 1.0

(but the arch linux package says sway 1.1.1-3)

Sometimes when I am using my sway desktop as usual the mouse cursor stops functioning. The first symptom I notice is that I can no longer scroll and cannot click on the parts of the user interface that are related to sway like the workspaces in swaybar and the window bars in tabbed containers but clicking in other windows still works. The automatic focus switching when moving the cursor to a window also stops working.

After some time of continuing to use the desktop the mouse becomes unable to click on anything at all. I can move the cursor no clicks register anywhere.

In this state I have unsuccessfully tried:

• pressing reload configuration hotkey
• locking and unlocking the screen
• closing all visible applications

Eventually I press the exit sway hotkey. The button asking me to confirm the exit does work with the cursor.

I do not know what causes this problem to appear.

The only mouse related configuration option I use is

input "identifier_of_mouse" {
    pointer_accel 0
}

Edit: My original problem was related to faulty input hardware on my side. I am not closing the issue because other errors have been discussed here too.

[RedSoxFan]

Can you try updating wlroots? https://github.com/swaywm/wlroots/pull/1717 might have helped this situation

[e00E]

I have upgraded to the git versions of sway and wlroots. I will update the issue if it still happens or close it in a week if it does not.

[luispabon]

I have noticed this, or something similar, happening occasionally when I'm using Virtualbox with both its gui and the guest os' gui open. Clicks don't register on any xwayland (keyboard is fine) app until I quit virtualbox. Clicks DO register on some (not all) native wayland apps though. Happens once in a blue moon and have yet been unable to capture in a debug-on sway session. Normal debug just says a line or two on some error in xcb.

[e00E]

What I described in the first post just happened again while using the git versions of sway and wlroots so it does not look like the linked pull request fixes it.

[e00E]

I mentioned previously that I was able to click the exit confirmation button. Just now I was not able to click that either.

[Jamedjo]

Something similar has been happening to me, I think related to starting sway with a second screen already plugged in. Unplugging it allows me to click things again.

[e00E]

I am using two screens as well. I will try unplugging next time.

[e00E]

Had this again but unplugging did not help.

[RedSoxFan]

If anyone can replicate this, can you please post a debug log along with the output of both swaymsg -t get_inputs and swaymsg-t get_outputs?

[e00E]

I managed to fix the problem by replugging my keyboard. This has worked 2 out of the 2 times I attempted it. I have attached the inputs and outputs captured while the bug was not active. I do not have a debug log.

The keyboard I was actively using and that I replugged is Keyboardio_Model_01. This keyboard can also act as a mouse. This seems relevant now so I apologize for not writing about that detail earlier. I do not actively use its mouse function but I might invoke it by accident.

There is another keyboard connected which I was not touching and conventional mouse. When I was referring to the mouse not working I meant this mouse.

It seems possible that this is a bug with having two mice connected at the same time. It could also be that it is a bug on the keyboard/mouse hybrid side. I have tried pressing all the buttons that invoke mouse actions on the keyboard but could not reproduce the problem. I have not tried using the keyboard mouse when the other mouse is in the bugged state.

With this we have 3 different potentially unrelated descriptions (Virtualbox, replugging monitor, replugging keyboard/mouse) for this bug.

get_inputs.txt get_outputs.txt

[luispabon]

I don't believe the virtualbox issue is related to this, but to its input grabbing feature. Happens one of every 10 graphical virtualbox sessions I open.

[unresolvedsymbol]

I replicate this all the time when debugging X applications, if say a game hits a breakpoint while having captured mouse focus, other X applications won't receive mouse input at all. This should be a issue in wlroots as mentioned, though. I think this is a critical bug and could even require someone to restart sway and close all their programs if the causing application won't respond to a SIGTERM. It very often requires me to use my (thankfully) native wayland terminal to SIGKILL the guilty process.

[abmantis]

I'm also having this problem. Repluging stuff (keyboard, mouse, display) does not fix it. Only closing virtualbox restores the mouse behavior.

[unresolvedsymbol]

@abmantis What I did when I ran into this issue on VirtualBox was to use a different input device (my laptops touch screen) to go into devices and plug/unplug the mouse device in USB emulation. Obviously not everyone has this though (and if they did use it, they'd probably opt out of using a tiling wm)

[abmantis]

@unresolvedsymbol thanks for the tip. My laptop does not have a touchscreen, but I've tried using the touchpad and the mouse without success.

[jameswalmsley]

I have also experienced this. I reset back to wlroots 0.7.0 and sway 1.2 and things work again. It seems to be with a multiple monitor situation, then one monitor send clicks to the correct location but not on the other output.

I can provide more feedback if required...

[nivekuil]

The keyboard I was actively using and that I replugged is Keyboardio_Model_01. This keyboard can also act as a mouse. This seems relevant now so I apologize for not writing about that detail earlier. I do not actively use its mouse function but I might invoke it by accident.

I also experience this, using a model 01. When it happens I just bounce to another tty and sway gets unstuck.

[emersion]

Can you see the events in sudo libinput debug-events?

[abmantis]

Not sure if it has been mentioned, but Wayland apps seem to work fine. This is only happening in X apps. I can still see the mouse click events in libinput.

[jameswalmsley]

Further info: Can also confirm that this seems to affect xwayland applications only. And my previous assertion about 0.7.0 and 1.2 not being affected was bogus.

I have the following setup:

output eDP-1 resolution 1920x1080 position 0,0 enable
output "Goldstar Company Ltd LG Ultra HD 0x0000661B" resolution 3840x2160 position 1920 enable

In this situation clicks work on the 4K monitor towards the left hand side, towards the right they are not passed through. (Possibly stopping at 1920 ???).

Going to swap positions and see what the difference is.

[jameswalmsley]

If I swap the positions:

output eDP-1 resolution 1920x1080 position '3840,0' enable
output "Goldstar Company Ltd LG Ultra HD 0x0000661B" resolution 3840x2160 position 0,0 enable

Then I can click anywhere on the 4K monitor but nowhere on the small eDP monitor.

Before the small eDP monitor allowed me to click anywhere.

[jameswalmsley]

Ok can confirm that click pass up to 1920 pixels (half the screen).

[jameswalmsley]

Also to confirm, running firefox with MOZ_ENABLE_WAYLAND=1 does not suffer from this issue.

[jameswalmsley]

If I create 2 output with the same resolution then the primary (position 0,0) output receives clicks. However the 2nd monitor receives click nowhere.

[jameswalmsley]

Going back to sway 1.0 and wlroots 0.5 does not have this issue. Probably doesn't help that much.

[jameswalmsley]

Ok, I've now tested this on a fresh Ubuntu 19.04 and everything works fine. (The broken system is ubuntu 18.04).

I'd say this is a bug from an old xwayland version.

Going to build xwayland from source and see what happens.

[jameswalmsley]

Ok I can confirm that after compiling the Xwayland from xserver master branch then this issue goes away.

[abmantis]

@jameswalmsley I have this issue on 19.04 also a lot of times when using VirtualBox (not always).

Btw, you can edit your comments here (no need for 8 consecutive comments :D )

[luispabon]

I also have this problem with 19.04's x server

[jameswalmsley]

@abmantis Interesting. I'll try installing virtual box and see if I can reproduce.. it may be that I've found a different but similar issue.

Thanks for the edit tip. I was deep in a big debugging session. I'll go in and edit tomorrow and clean it up.

[luispabon]

Unfortunately sway doesn't work correctly under any of vbox graphics cards.

[abmantis]

@luispabon the problem happens when I use VBox in sway, not sway in VBox. The virtual machine has windows, but that probably does not matter.

[jameswalmsley]

@luispabon it's possible that I compiled Xwayland on my 19.04 machine and forgot about it. I'll double check tomorrow and let you know.

[luispabon]

Albilio I realise that as I have the exact same problem. Just want to manage your expectations running sway in virtualbox to test anything, it's a pretty poor experience and I doubt it translates well to bare metal.

[jameswalmsley]

@luispabon @abmantis I've confirmed that my other machine had an own compiled Xwayland installed. Also tried virtualbox and that seems to work fine.

Will try a few more times to ensure its not intermittent.

[cnyk]

Same behaviour on Fedora 30. Wayland apps work fine. sway-1.2-2.fc30.x86_64 (compiled from fedora rawhide src.rpm) xorg-x11-server-Xwayland-1.20.5-7.fc30.x86_64

[e00E]

I still maintain that we are talking about at least two different issues in this thread. There is a problem with virtualbox and there is a problem with Keyboardio_Model_01 users.

Feel free to keep talking about the virtualbox issue especially since it looks like we made more progress with identifying that one but I wanted to have this stated clearly once.

[luispabon]

Roger that.

xwayland in ubuntu 19.04 is 1.20.4

[jameswalmsley]

@luispabon My oldest working build was from Xwayland built from xserver master using commit: xorg-server-1.20.0-215-g7fb6338c6

(My new setup uses: xorg-server-1.20.0-428-gbcf2dd0cd )

I don't think this matches up to the ubuntu version numbers exactly. Perhaps built with a different config...

I followed the build instructions on: https://wayland.freedesktop.org/xserver.html

It will install Xwayland into /usr/local by default, so won't break your Ubuntu system. Also I had to copy /usr/bin/xcbcomp to /usr/local/bin/xcbcomp to make it work.

@e00E That sounds like a different issue sorry for polluting this issue. Hope we can find a solution to that too.

[abmantis]

Any progress on this? Is more info needed? Previously the issue would only happen in half the times I used VirtualBox, but now it happens all the time.

I also found that sometimes the problem doesn't happen right away. It can take some minutes to "disable" the mouse.

[daviian]

I've to add that this issue is not VirtualBox related. I've this issue on my arch installation as well.

New to sway, so if someone can guide me to be of any help in this issue?

[gwaterst]

Just to mention: the problem with the mouse cursor in Virtualbox is not a sway problem. I experience the same problem in Virtualbox when having a gdm session (no sway) with wayland enabled while the problem disappears when working with Xorg. I am on Arch as well - given the fast update policy it might be an xwayland-virtualbox incompatibility.

[wiktor-k]

It's definitely not related to Virtualbox only as I don't have VB installed and still had this issue happen (mouse cursor moves but no clicks registered or workspace/window focus change). I'll get back when I collect debug outputs.

Edit: interesting workaround: I've got a second mouse connected. Moving it (or clicking?) fixed the issue with the first one.

[JonasKs]

I have the same issue. Sway 1.4, wlroots is from master about a week or two ago. RHEL8, no VB or anything installed.

[emersion]

When the mouse is "stuck" like this, can you run sudo libinput debug-events and see if mouse click events appear there?

[JonasKs]

When it happened just an hour ago, my mouse didn't work in any application but Firefox for a little while. I tried changing window with the mouse instead of SUPER+L and then it stopped working in Firefox too.

I've rebooted now to fix the issue, but I will run that command next time it happens.

[FreeFull]

@JonasKs That sounds like a different issue. In the original issue, the input from the touchpad just wouldn't have any effect at all

Edit: Sorry, I confused this issue with another one. Reading the first post, this does seem to be the same issue you're experiencing.

[piatikantrop]

Still happens frequiently. Running sudo libinput debug-events detects clicks and scrolls but no response from the app.

[olabri]

do you use negative screen coordinates? that was the reason for me

https://github.com/swaywm/sway/wiki#mouse-events-clicking-scrolling-arent-working-on-some-of-my-workspaces

On 04.03.2020 20:26, Denis wrote:

Still happens frequiently. Running |sudo libinput debug-events| detects clicks and scrolls but no response from the app.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/swaywm/sway/issues/4261?email_source=notifications&email_token=AAMU7626Z5XHYA4POCYRPYTRF2TOTA5CNFSM4HYWMFKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENZYZNQ#issuecomment-594775222, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMU762J655WCDIXBNY2H5TRF2TOTANCNFSM4HYWMFKA.

[JonasKs]

That seems like a “permanent” effect, though? What we’re experiencing is a sudden loss of mouse clicks. It seemed to happen out of the blue on a one monitor setup(I didn’t have my dock connected at the time). I’ve only experienced it once while working so didn’t really have time to troubleshoot.