(Bounty US$100) Keyboard & mouse stops responding. Need to pkill X to resolve

I'm running a Thinkpad T14 AMD Gen1 with Mate 23.04.

X (with Mate as the window manager) will stop responding to keyboard inputs (except for CTRL+ALT+F1). Mouse clicks stop working but you can still move your mouse around and on mouse over popups still work; if there's a video-call going on it continues to work just fine, but you can no longer control it as you can't click or use keyboard.

The only way to recover from this is CTRL+ALT+F1 to get to a terminal and then pkill X ; going back and forth from CTRL+ALT+F# to CTRL+ALT+F7 does not unstuck the keyboard/mouse unresponsiveness (but whatever applications were running, including a video-conference) continue to work just fine despite the switching.

Edit I'm offering a bounty of US$100 to solve this problem. Payment via Google-Pay or PayPal

1 Like

The only thing I can think of with this exact behaviour (including keyboard not working) is when some rogue app is stealing focus and won't give it back.

When this happens, is there some modal window hiding behind other windows that cries for attention ?


Context robbing is something I was looking for. It is impossible to Alt-Tab or minimize everything and bring up the desktop. X11 is completely irresponsive to input. The only thing that works is CTRL+ALT+F1 to go to tty terminal. Is there any way to send a message to X11 to reset keyboard/mouse from the TTY terminal?

As far as I know you can probably steal the keyboard back with a sysrequest command (although I don't know how far its scope reaches):
Press these keys together: AltSysreqR
Or: AltShiftPrtScR
More info about this:

This is the list of systemrequest commands:

And getting it to work in debian/ubuntu:

Also this:


So let me get this clear: You boot up, log in, and initially your mouse and keyboard work fine at the desktop; everything is copacetic. Then at some point in your session, all of a sudden and out of the blue, your keyboard doesn't work and your mouse clicks stop having any effect, though you can still move your mouse. Ctrl-Alt-F1 (and presumably the other "F" keys) still work though, and you can even switch back to X11 with Ctrl-Alt-F7.

Now, you said above that if you hover over something that is activatable just by hovering over it, that the object will activate -- e.g. a popup will appear. Can you tell us just what kind of popup this is, such as what application it's in? Is it on a Web page or is it in a desktop application, for example? I've seen that Web browsers can sometimes display popups even when some other application is grabbing the keyboard and mouse. It's weird how they do that.

Also, which applications do you have open when this strange behavior occurs, if I may ask? This is an important question to answer. Clearly, this behavior is caused by some application grabbing input focus; it could be the MATE Screensaver, it could be Firefox (the annoying "Update Available" popups have a strong tendency to do this -- believe me, I have experience with this), it could be something you didn't even know you were running. But if maybe the next time you encounter this problem, you can at least look down at the Window List on the panel and make a note of what you have open, and also note down what window was actively on top on the screen at the time of the unresponsiveness, that would be very useful.

Finally, while @tkn's advice about Alt-SysRq-R was well-intentioned and generally good advice, I find it very unlikely to actually work for you. If the system responds to Ctrl-Alt-F1 when this grabbing stuff happens, then clearly the kernel (and even X) is still receiving input from the keyboard and responding to it. Similarly, if moving the mouse works, the mouse driver still works too. So "restoring" the keyboard to a "normal" state is probably not going to work, since the keyboard itself is already in a normal state.

However, if you could, there is one other thing I'd like you to try when this next happens. When the weird grabbing behavior occurs, switch to the console (Ctrl-Alt-F1), and log in there as the same user account as which you're logged in on X. Then, still at the console, run the following commands:

sudo apt install xdotool
DISPLAY=":0" xdotool key "XF86LogGrabInfo"

Then, still at the console, look in the logfile for the X server, at the bottom or near-bottom of the file:

less /var/log/Xorg.0.log

...or, if you've already pkill'ed the X server at least once, possibly:

less /var/log/Xorg.1.log

(you might need to run these as sudo).

According to this Unix & Linux Stack Exchange post, you should see an entry in the logfile that looks something like this:

[1199428.782] (II) Printing all currently active device grabs:
[1199428.782] Active grab 0x4c00000 (core) on device 'Virtual core pointer' (2):
[1199428.782]       client pid 15620 /usr/lib/firefox/firefox 
[1199428.782]       at 1199423728 (from active grab) (device thawed, state 1)
[1199428.782]         core event mask 0x7c
[1199428.782]       owner-events true, kb 1 ptr 1, confine 0, cursor 0x0
[1199428.782] (II) End list of active device grabs

At the very least, it should tell you the process ID and name of the offending grabber. In this example, Firefox can't seem to keep its hands to itself. :wink:

I excittedly await your reply and new information regarding this issue -- assuming it didn't spontaneously go away. Always a possibility; maybe an upgrade fixed it.

Thanks in advance.


Gordon, thank you for your reply.

To answer your question: most of the time I'm in chrome - that's where I spend the vast majority of my day (in gmail or google-meet or zoom or ms-teams or google-slides with meet presenting the slides, always in chrome), also I use zotero which is an electron app. I use Brave for my home email, and android-web-sms so it's open most of the time, but I'm rarely in there.

I do look for additional windows that are open when the system stops responding -- never saw anything other than the few windows I was working on.

I installed xdotool and will run the command as soon as the problem happens again. I've also reset the about://flags in both brave and chrome and upgraded the kernel today... lots of changes!


@gordon / it just happened again. I was in chrome trying to paste data into a table in gmail.
I ran the commands you suggeted. .
Here is Xorg.log file after running xdotool command

That Xorg.log you gave me is positively huge, and at first I was totally daunted by its size. I was wondering how I was going to make any sense of it, when I stepped back, looked at it from the top, and noticed this:

[ 64514.203] (II) Printing all currently active device grabs:
[ 64514.203] Active grab 0x4e00000 (core) on device 'Virtual core pointer' (2):
[ 64514.203]       client pid 106405 rofi -dmenu -i -p HUD -lines 10 -dpi 96 -separator-style none -hide-scrollbar -click-to-
exit -line-padding 2 -kb-cancel Escape,Alt_L -monitor -2 -theme mate-hud-rounded [...]
[ 64514.204] Active grab 0x4e00000 (core) on device 'Virtual core keyboard' (3):
[ 64514.204]       client pid 106405 rofi -dmenu -i -p HUD -lines 10 -dpi 96 -separator-style none -hide-scrollbar -click-to-exit -line-padding 2 -kb-cancel Escape,Alt_L -monitor -2 -theme mate-hud-rounded [...]
[ 64514.204] (II) End list of active device grabs

(Much irrelevant text has been deleted to better highlight the interesting parts.)

Sure enough -- that output would indicate that there is a keyboard and mouse grab taking place when you encounter this weird freezing behavior. The log indicates that a program called rofi is the culprit. I was scratching my head about what the heck this rofi thing was, when I also noticed the mention of mate-hud on the same line as rofi in both places. If my memory serves me right, the MATE HUD is a program that normally sits quietly in the background, but when you press the Alt key (the left one to be precise), it pops up a menu of the currently-focused application's menus. From there you can type to search for a specific entry in the application's menus, so that you don't have to drill through a dozen or more menus to find what you're looking for.

So, long story short, somehow the MATE HUD is getting activated when you don't want it to be activated. Probably, you accidentally hit the left Alt key without pressing another key simultaneously; so for example, instead of pressing Alt-S, you maybe pressed Alt and then immediately released it. That activated the MATE HUD, which grabbed the keyboard and mouse.

To test my theory, the next time this happens, press and then immediately release the left Alt key again. That is supposed to dismiss the HUD. If that doesn't work, try Esc; that is also supposed to work. And finally, if all else fails, log in at the console (Ctrl-Alt-F1) and kill rofi to forcefully break the grab:

pkill rofi

Obviously, if you don't ever actually use the MATE HUD, you can disable it entirely: I think there's an option under the MATE Tweak tool now to enable or disable the HUD. Alternatively, if you do use it but it's too annoying to have it activated every time you tentatively press the left Alt key, I think there's a special MATE HUD Preferences dialog with an option to change the key that activates the HUD. You might want to change that keystroke to something else that doesn't get in the way of your work so much.

Finally, if that is not the culprit, or if you're not pressing the left Alt key when this happens, then let me know. Maybe the MATE HUD (or rofi) has a bug that we should report!

I hope that helps, and thanks in advance.


@gordon you got it! rofi is the culprit.

I killed rofi from the terminal (reached via) ctrl+alt+f1 and that worked!

I used to use mate-hud all the time because libre-office menus were hard to navigate until Libre implemented shift+esc to search the menus (~1 yr ago?). Since then the only use case for mate-hud is gimp because the menu system is still unnavigable.

I disabled hud from mate-tweak and removed the package mate-hud using aptitude

  1. What debug info do we need to provide the maintainers of rofi --- I remember that mate dropped support for the HUD before 22.04 because it was too hard to maintain. So perhaps there is no one who is watching for compatability issues.
  2. Where can I send the bounty to! THANK YOU. (PM'ed you).

Well, good to see that we found the culprit!

As for where to report the issue, looking around the Web a little more, I found out that this has been a recurring problem with the MATE HUD for a while (since at least 2017). It looks like if you're going to report this as an issue, you should report it not to the Rofi maintainers, but to the MATE HUD maintainers. The best place I could find to report it is at Causes all keyboard input to be ignored · Issue #30 · ubuntu-mate/mate-hud · GitHub, because that issue sounds identical to the problem you had and the issue is technically still open (though no activity on it since 2018, oddly!).

It might be better, though, to report it at mate-hud is causing a complete input deadlock · Issue #16 · ubuntu-mate/mate-hud · GitHub instead. Even though that issue is closed, @Wimpy himself was involved in that issue, and maybe he'll have some better idea of how to fix this than somebody else. I don't know.

Either one will require you to create a GitHub account if you don't have one already. I already have an account (for doing development work), so if you want me to be your proxy and write something in one or more of those issues for you, I'd be happy to do that.


@jonpolak just paid me the $100 he promised to whomever could solve this issue. While I don't believe I have actually solved the issue per se, I understand that he is satisfied with at least knowing what the problem is and knowing that the problem won't come back (since he uninstalled the MATE HUD entirely).

@jonpolak suggested in a private message to me that more people should offer monetary rewards to anyone who can solve their problems. He suggests that such bounties would result in more problems ending up getting solved, and the issues would get solved faster too, since prospective troubleshooters in this community would have more motivation to find real solutions.

I think Jonathan is right about that: When people post new threads/topics about some issue or bug they've run into, it's a real problem for that person. It may not seem like much of an issue to anybody else who comes along, though: Maybe the person with the issue is trying to do something pretty unique, or has an unusual hardware configuration, or maybe it's just that nobody else on the community forum uses or has any interest in [fill-in-the-blank-application]. But put money behind the issue -- even smaller amounts of money -- and maybe it'll be enough to get somebody interested enough to look into the issue and actually care about solving it. Let's face it: It worked on me.

Just thought I'd publicly show that Jonathan fulfilled his promise, and I wanted to thank him for that and share that advice he shared with me. Thanks again @jonpolak!


We didn't debug Mate-HUD ; we did what was necessary to get back to work! That's a problem solved in my book.

Bounties to go after the top 500 annoyance bugs would make Ubuntu Mate more solid for all of us! I know that actually administering this will be much harder than it sounds.