sway: Mouse cursor can no longer click on anything or change focus

$ 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.

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Reactions: 16
  • Comments: 105 (7 by maintainers)

Most upvoted comments

I have the same issue on 1.8.1, after my last distro upgrade. Switching to another TTY and back resolves it.

I can also confirm that changing negative output positions to positive fixed the issue for me.

output DP-1 resolution 3840x2160 position 0,0
output DP-2 resolution 3840x2160 position -3840,200

to

output DP-1 resolution 3840x2160 position 3840,0
output DP-2 resolution 3840x2160 position 0,200

Also, only xwayland applications were affected from what I can tell (Discord, slack, skype, quasselclient)

Came here with the same issue where I couldn’t click on a window when it was placed on a secondary display. I had negative coordinate positions in my output configuration.

output $laptop pos 0 0 res 1920x1080
output $external pos 1920 -1080 res 3840x2160

I replaced it with the code below, the window works fine now!

output $laptop pos 10000 10000 res 1920x1080
output $external pos 11920 8920 res 3840x2160

I’m going to guess something doesn’t deal well with negative offsets. If it matters, I only found the issue in vscode which I believe still runs XWayland.

Can replicate this with swaylock and closing the lid of my laptop while Firefox is open. I have an AMD Ryzen 7 4750U if that matters (saw it mentioned earlier in the thread). Can be worked around by switching to another TTY and then back.

The problem is in Swaylock on lid close (sleep) with Nvidia drivers running on wayland. I uninstall nvidia, nvidia-dkms, nvidia-gtklibs, nvidia-libs and problem solved.

It doesnt happen when you manually invoke “swaylock -f” but when you close lid and open it back, mouse, keyboard wont response, also it wont allow to go to tty.

I am not using swaylock or nvidia

The following may help for those who are having the VirtualBox cursor/pointer grab issue (where you can move the mouse on the host but clicking doesn’t have any effect until you quit the VM). Since this issue is mentioned here, I thought I’d post what works for me. This was on a regular Xorg session, but hopefully it helps on Wayland as well.

Workaround: force an ungrab, so you don’t have to close VirtualBox to get mouse clicks to work again.

#!/bin/sh

fix() {
    local options="$(setxkbmap -query | grep 'options:' | rev | cut -d ' ' -f 1 | rev)"

    # Simulate the ungrab.
    setxkbmap -option grab:break_actions
    xdotool key XF86Ungrab

    # Restore previous options, because leaving grab:break_actions enabled
    # could otherwise introduce a security risk, possibly allowing screensavers
    # to be bypassed, as mentioned here: https://unix.stackexchange.com/a/40472
    setxkbmap -option # Reset options.
    setxkbmap -option "$options"
}

fix

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.

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?

Hi - I have been seeing this issue for a few months. Recently it’s started getting more frequent.

I use sway on Arch. Firefox and wezterm are >90% of the use. Dual monitors, side-by-side. Laptop sits on the left. Desktop on the right. I regularly switch the left monitor between extending my macOS laptop to extending the Linux desktop screen. (I have a script that uses wl-randr and ddcutil to switch things around). I use waynergy on Sway and Barrier on macOS to share mouse and keyboard.

As reported above in this thread, occasionally my mouse would not allow me to click and focus-follows-mouse would stop working. Keyboard had no issue and I can navigate around using keyboard shortcuts.

I could never figure out why this was happening, or how to reset or regrab the mouse so it would start working again. I’ve tried killing Xwayland, debugging waynergy etc. Only a new sway session or reboot would fix.

However - I now realise - as of about 30minutes ago that when I killall firefox, I get the mouse control back and all is working as normal.

Until it happens again a few minutes later. then I kill firefox and - as if by magic - it all works again. For a few minutes.

So - is there any troubleshooting I can do to help? I seem to be able to reproduce this easily.

❯ pacman -Q | grep -Ee '(xwayland|wlroots|sway|waynergy|wezterm|firefox)'
firefox 119.0.1-1
sway 1:1.8.1-3
swaybg-git r128.a67361e-1
swayidle 1.8.0-1
swayimg 1.12-2
swaylock 1.7.2-1
swaync-git v0.9.0.r2.gffb33de-1
swayr 0.27.0-1
waynergy-git r322.9b62bf0-1
wezterm-git 20230922.143151.0f894d79-1
wlroots 0.16.2-2
xorg-xwayland 23.2.2-1

❯ echo $MOZ_ENABLE_WAYLAND
1

EDIT - Oh no… As I was typing this comment, the issue occurred without firefox being open. Back to square one. I’ll leave this comment in case it’s useful.

I noticed that with all windows closed, I can’t click on waybar, but if I pop up swaynag, then I just need to click above waybar (on the swaynag toolbar) and clicks are registered on the waybar. Meaning clicks are offset on the Y-axis. Not sure if it’s a symptom or a cause of the issue.

having tried that solution several times it doesn’t appear to work for me.

It doesn’t work for me usually anymore either 😦.

Can replicate this with swaylock and closing the lid of my laptop while Firefox is open. I have an AMD Ryzen 7 4750U if that matters (saw it mentioned earlier in the thread). Can be worked around by switching to another TTY and then back.

I’m not using the local mouse and keyboard when this happens (waynergy) and having tried that solution several times it doesn’t appear to work for me.

I just wish that any kind of debug logging would give evidence of what happens, as thus far no one’s attempts in this thread with debug logging of sway, libinput, or even generic wayland debug logging have revealed messages specific to this problem.

Does anyone have a workaround for this? I have to SSH into the system and kill sway just to be able to click again.

I also have these issues, but not using Waynergy. Just as described above, changing temporarily to another TTY and back, brings back the ability to click and scroll correct window (focus follows mouse) using the cursor.

Moving the cursor works all the time.

Did you try this?

I have tried the suggestion from bughunter, which did not work, but I have not tried TTY-switching. I’ll try that next time.

Does anyone have a workaround for this? I have to SSH into the system and kill sway just to be able to click again.

I also have these issues, but not using Waynergy. Just as described above, changing temporarily to another TTY and back, brings back the ability to click and scroll correct window (focus follows mouse) using the cursor.

Moving the cursor works all the time.

Did you try this?

My eventual fix this time was to suspend the laptop to ram and then resume.

Thanks for the workaround !

I can also confirm that apparently it was the use of a negative position for the external display that was preventing the mouse from working in the external display for me. Putting the primary display at 10000,10000 was sufficient to made all position coordinates be positive.

Hello everybody.

I am new to Sway and Wayland and I am hitting this issue too.

Weird is that for me mouse can be stuck with previously focused application. And when I have horizontal split screen - moving mouse over affected window (chromium) didn’t work, but when I moved my cursor over the other window, scrolling was affecting the other window.

Software

  • Alpine Linux 3.11.5
  • Sway 1.2 R1
  • sway version v20191114-552-geeb2777b45 (Oct 11 2019, branch ‘master’)
  • wlroots 0.8.1 R0
  • alacritty 0.4.0 r2
  • chromium-79.0.3945.130-r0
  • wayland-libs-cursor-1.17.0-r0
  • wayland-libs-egl-1.17.0-r0
  • xorg-server-xwayland-1.20.6-r0

Configuration

Is default plus small additions

## my config
gaps inner 8

## follow windows with mouse
mouse_warping output
#focus_follows_mouse yes
focus_follows_mouse always

smart_gaps on
smart_borders on

Not sure how to check if I am using negative coordinates or not, but I know have ultra-wide screen … if it is relevant at all or not, dunno.

Note: I still need to run sudo libinput debug-events 👼

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.

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.

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

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.