pop-os / pop

A project for managing all Pop!_OS sources
https://system76.com/pop
2.44k stars 87 forks source link

Mouse goes berzerk after resume from idle (S1) #466

Open KloudKoder opened 5 years ago

KloudKoder commented 5 years ago

Distribution (run cat /etc/os-release):

All, even other Linux flavors

Related Application and/or Package Version (run apt policy $PACKAGE NAME):

Not sure, but it has something to do with resume from S1.

Issue/Bug Description:

Lock the screen (S1), but don't suspend (S3) by closing the lid. After the screen goes black, shake the mouse or hit a key to wake up. About 20% of the time, all hell breaks loose. The reason is that mouse movements and mouse clicks seem to have been confused, probably due to a desynchronization between the kernel and the mouse state. I've tried multiple mice and also the trackpad. It doesn't matter what I use, this bug is still there. I first noticed it 2 years ago on another Linux.

Back in the PS2 era, mouse drivers would automatically detect desynchronization by doing online statistical analysis of the input stream. When it's detected, the best action is to reset the mouse.

Unfortunately, this resync doesn't seem to happen very quickly in Linux. My mouse goes insane for 10 minutes, clicking random stuff and even sometimes bringing up a virtual keyboard and typing!

It's possible to detect desynchronization within a hundred mouse samples. So it could be reset within a second of the problem occurring.

Steps to reproduce (if you know):

Explained above.

Expected behavior:

Detect desynchronization, smack mouse into proper behavior with device reset. Keep doing this whenever it desynchronizes.

Other Notes:

Sometimes, just maybe, it's possible to work around this by locking the screen again and again until the mouse gets its act together. Not fun.

mmstick commented 5 years ago

This sounds very hardware-specific. You'll need to post your model, and perhaps look around to see if any workarounds are required for your model.

KloudKoder commented 5 years ago

@mmstick Without a doubt it's hardware-specific. The issue is that this problem has been relatively common since the mouse was invented, so it's reasonable to expect the driver stack to handle it gracefully. Sometimes the episodes are so bad that I can't even reenter the locked screen state, and I need to power down. I've already been down the route of workarounds for my machine, and unfortunately there's really nothing available.

KloudKoder commented 5 years ago

I have a feeling that all these are related by improper or incomplete entry/exit to/from idle or sleep (S1 or S3):

463

solus-project/budgie-desktop#1374 solus-project/budgie-desktop#1082

466

bwat47's workarounds in the first 2 appear to be effective for me, although it's hard to be sure because these bugs don't occur every time, and might literally depend on the temperature.

Secondly, here's what to do if you come back to a messed up screen or a crazy mouse pointer. Just to be on the safe side, save everything before you test this. Also, don't attempt it at the digital clock screen; instead, wait til you're at the login prompt or the desktop.

Push Ctrl+Alt+F11
Wait until the screen settles down, usually to black or some weird error message
Push Ctrl+Alt+F2
Wait til the desktop restores
If still abnormal try this all again

These key combos seem to be hardwired into GNOME. I actually discovered the first one by accident, and didn't know to get out of it. Unfortunately, there's no way to turn them off under the keyboard settings, so it's an accident waiting to happen (and who would guess that Alt+F2 is the way to undo it?!). But now, these "features" are you friends because they protect you from the disaster that is bad sleep/wake behavior.

One final hunch is that all this points back to quality problems with the Intel video driver. This is a compelling theory based on a lot of reading, but I have no proof. Indeed, on every single boot, my login screen goes crazy with video problems, likely due to the same underlying bug.