Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mate-hud is causing a complete input deadlock #16

Closed
flexiondotorg opened this issue Nov 17, 2017 · 19 comments
Closed

mate-hud is causing a complete input deadlock #16

flexiondotorg opened this issue Nov 17, 2017 · 19 comments

Comments

@flexiondotorg
Copy link
Member

flexiondotorg commented Nov 17, 2017

@vkareh After some more thorough testing mate-hud 18.04.0 is causing a complete input lock up for keyboard and mouse.

This can be reproduced using mate-hud from git master on Ubuntu MATE 18.04 with a layout activated that uses the Global Menu, such as Mutiny, Cupertino or Contemporary. I was able to create the deadlock by invoking things that required Alt, such as Alt + PrtScn or Ctrl + Alt +t. It doesn't happen 100% of the time but after a few uses of Alt the lock up happens. The only recourse is to switch to a vt and kill mate-hud then switch back to the desktop vt.

The best way to test this is using the Ubuntu MATE 18.04 daily live image on actual hardware and replacing mate-hud with the version in git master.

Reverting this patch resolves the issue:

So I will publish a new .deb that reverts that commit via patch for the time being 😄

@vkareh
Copy link
Member

vkareh commented Dec 4, 2017

@flexiondotorg - I made some fixes to the code, but I still the get input deadlock ocassionally. However, it only happens when mate-hud is started along with the desktop environment. If I run mate-hud after the computer is fully booted, I don't get the input lock. I have vague memories of this being an issue for earlier iterations of mate-hud during the 17.10 dev cycle and I think I remember you changing where/when in the boot process it gets loaded. Could it be related?

@flexiondotorg
Copy link
Member Author

@vkareh I've been making some unrelated changes to mate-hud this morning and managed to encounter a deadlock, the was output to stdout just before the lock up happened:

<class 'Xlib.error.BadAccess'>: code = 10, resource_id = 518, sequence_number = 22, major_opcode = 28, minor_opcode = 0

@flexiondotorg
Copy link
Member Author

@vkareh I may have found a solution. I will test over the coming days to confirm. Looks like it may not be a mate-hud issue.

@flexiondotorg
Copy link
Member Author

Sadly I was wrong, the lockups still happen.

@vkareh
Copy link
Member

vkareh commented Feb 12, 2018

@flexiondotorg - damn, I was both curious and hopeful for a while there. No worries, the BadAccess error is actually quite helpful! I'll work on a fix this week - this issue has been driving me insane!!

@flexiondotorg
Copy link
Member Author

@vkareh I'm using the new release with the potential lock-up fix, sadly I just experienced a lock up. I run Compiz so I am now testing to Marco to see if that is a factor.

@flexiondotorg
Copy link
Member Author

Locked up with Marco too.

@vkareh
Copy link
Member

vkareh commented Feb 17, 2018

Yeah, same experience here. However, if I start it directly from the command line after the desktop is fully up, I don't get the locks... :/

@flexiondotorg
Copy link
Member Author

I'm still experiencing lock ups with d4d57e4 applied. I'll test with the Whitelist Caja navigation shortcuts change applied.

@vkareh
Copy link
Member

vkareh commented Feb 26, 2018

Okay, back to the drawing board :/

@flexiondotorg
Copy link
Member Author

Two hours of mate-hud being active with #21 applied. No lock ups so far...

@flexiondotorg
Copy link
Member Author

Just had a lock up.

@vkareh
Copy link
Member

vkareh commented Feb 26, 2018

I'm testing extra checks, like wrapping the entire keybinding processing block in try/catch and call allow_events if it ever fails - I'll test more on my side to see what happens...

Did #21 solve the caja navigation for you?

@flexiondotorg
Copy link
Member Author

Yes, #21 solved Caja navigation as best as I can tell. I've never used those keybindings in Caja before.

@vkareh
Copy link
Member

vkareh commented Mar 3, 2018

I haven't gotten an input lock up since the try-catch update. Have you? We should maybe keep this issue open for a little while longer, but I'm really looking forward to when we can close it!! :) :)

@flexiondotorg
Copy link
Member Author

flexiondotorg commented Mar 3, 2018

I have not. HUD is disabled by default, but the fix is released to Ubuntu. I'm thinking leave HUD disabled by default. Your thoughts?

@vkareh
Copy link
Member

vkareh commented Mar 3, 2018

I think we should leave it off by default. It decreases the chances of any remaining issues for users that don't want/need/expect the HUD. Mutiny should have it on, of course, as that's part of the overall experience, but other than that I think users that really want it will know to enable it.

@flexiondotorg
Copy link
Member Author

I've not experienced a lock up for nearly two weeks on multiple computers.

@jonpolak
Copy link

jonpolak commented Jul 30, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants