mate-hud icon indicating copy to clipboard operation
mate-hud copied to clipboard

Causes all keyboard input to be ignored

Open CreamyCookie opened this issue 6 years ago • 7 comments

The whole time I thought it's compiz, but it's actually the HUD. I only figured this out because someone else apparently stumbled on the same problem: https://ubuntu-mate.community/t/keyboard-stops-working-randomly/16759

After killing mate-hud from tty3, the keyboard immediately worked again. Does mate-hud provide log files that could help you fix this bug?

CreamyCookie avatar Jun 24 '18 13:06 CreamyCookie

I've found a way to fairly reliably reproduce this:

  1. Enable HUD and assign <Super>Space shortcut: gsettings set org.mate.hud shortcut '<Super>space'
  2. Install GIMP 2.10 from snap: sudo snap install gimp
  3. Open GIMP (note that it does not export its menus properly via dbus so has no Global Menus... this is relevant to mate-hud)
  4. Press <Super>space a couple times
  • Note the HUD does not appear
  • Usually this immediately freezes the keyboard
  • The Global Menu also seems to crash or hang

Edit: this doesn't seem consistent; the issue is still intermittent. Sometimes I've had to try triggering the HUD in other applications (Firefox etc.) before the issue will occur.

On my system I have Compiz enabled and <Super> Button4 and Button5 (mouse zoom) configured for Enhanced Zoom Desktop. I noticed that, once the keyboard is locked up like this, ALL mouse zooms trigger Enhanced Zoom Desktop.

It seems as though mate-hud grabs the <Super> keypress and never lets go if it can't access menus.

Switching to another TTY and killall mate-hud immediately unlocks the keyboard.

mdmayfield avatar Jul 16 '18 10:07 mdmayfield

@CreamyCookie , are you using an alternate keyboard shortcut or the standard Alt_L?

Glancing at the code, mate-hud seems to do a lot of keyboard-grabbing and -replaying tricks in order to enable tapping a modifier (Alt) to trigger. I suspect an edge case in one of those tricks causes this issue. Perhaps a simpler approach is warranted, when using an easier-to-parse shortcut? Edit: oops, looks like it already does this

mdmayfield avatar Jul 16 '18 10:07 mdmayfield

@mdmayfield Thank you for looking into this!

Oh, yeah, it seems I did change the shortcut at some point:

$ gsettings get org.mate.hud shortcut
'<Super>space'

Completely forgot about that. I've reset it now and re-enabled the HUD to try to see if the bug occurs in this configuration. I'm currently using Compton (GPU compositor).

CreamyCookie avatar Jul 17 '18 09:07 CreamyCookie

Haven't occurred to me again yet (with default ALT_L), so I assume it has to do with custom keyboard shortcuts not being properly handled.

CreamyCookie avatar Aug 09 '18 20:08 CreamyCookie

Confirmed.

When changing the shortcut to <Super>space, I can trigger a input lock under certain circumstances... still more research needed to determine what the pattern is to trigger the issue and why it's happening, but I can see a few places which might trigger the issue.

One thing that I think might affect this is that when changing the shortcut, we ungrab the existing one, but we don't ungrab the mouse clicks (used to allow Alt+drag).

vkareh avatar Aug 14 '18 15:08 vkareh

@vkareh I get the same with <Alt>space or even <Control>space.

I would recommend the following:

  • the shortcut will start the python script
    • the hud is now started, starts rofi, does it's job
  • after rofi is killed and the command is parsed to the application the python script should quit gracefully

This will mean the script will not run constantly, it will instead just open up on shortcut call and get terminated.

RaitaroH avatar Oct 16 '18 13:10 RaitaroH

Happening again on 23.04 (Ubuntu Mate). Same issues, using Alt (in combination with other keys, like control-alt-V). Killing rofi (the display agent called by mate-hub) solved the issue.

jonpolak avatar Jul 30 '23 21:07 jonpolak