[RESPONDED] Reasonable solution to "screen jumping / mouse freezing"

So, some users - I am one - occasionally experience “screen jumping”, where the mouse will freeze for a moment or two (or three), the screen will the hop and flicker vertically, and then return to normal, with this usually repeating every so many seconds, sometimes getting worse, sometimes recovering by itself.

Occasionally, the UI freeze fully and although the laptop still runs, mouse does not move, screen does not update.

For the former, I have found that shutting the laptop lid and re-opening it normally clears the problem. Not always, but it looks like every time you do this, you have a very good chance of clearing the problem, and so if I repeat, then the problem is solved. I can’t think I’ve ever needed to try it three times.

The latter is rare, and I cannot recall if this method helped or not.

If you are not the only one, why create a new topic and not add this comment to an existing topic ??

And it may be a solution for you but not these other users ???

I may be wrong, but I have the impression it’s somewhat common, and a solution is therefore important. Sticking it at the end of a 60 comment thread will tend to bury it.

1 Like

Maybe you could provide the information outlayed in this post so we can assist you.

1 Like

This please.

PLEASE READ BEFORE POSTING: Are you looking into the forum because you’re having potential issues with your Framework laptop? Before creating a post, we may have a guide, FAQ, or thread that can hopefully help!

In the body of your post, please include those following details.

  • Which OS (Operating System)?
  • Which release of your OS (Operating System)?
  • Framework laptop (11th or 12th generation Framework laptop) are you asking for support with?
  • If this is a Linux issue, please use the Linux tag or at least put Linux in the title.

If there is no information pertaining to your issue or question, please let us know here: Framework | Support

The post is of a solution to a problem, not a request for assistance.

2 Likes

I have had this problem since upgrading to the 12th gen mb last year. It’s why I’m finally here googling for threads about it. This description fits exactly, so, it’s a real thing whatever it is, not just one user who is “holding it wrong”.

1 Like

You are dealing with touchpad jumping as well based on your post on a specific Linux distro. Can you elaborate on the distro involved, kernel used and software in use when it happens? Helps us try to replicate this type of thing.

In the meantime, having an active terminal open with journalctl -f may offer us some insight as well. This should give us the error or issue in realtime which may help us figure out what is happening.

No touchpad jumping that I know of. If it glitches at the same time I wouldn’t know it because I almost never use the touchpad.
I’ll check journalctl next time it happens.

1 Like

Well it just happened again. No activity in journalctl -f while actively glitching.

I didn’t have any apps open yet, it was right after reboot and it was just sitting at the xfce desktop.
I started journalctl -f and then let it continue glitching eventually some new log entries came along, but not timed with the glitches.

The last few messages already in there before looking were:

Mar 31 16:03:23 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:03:23 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:03:32 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:03:32 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:03:35 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:03:35 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:04:21 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:04:21 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:04:29 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:04:29 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:04:34 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:04:34 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:04:34 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.
Mar 31 16:04:34 fw rtkit-daemon[1617]: Supervising 8 threads of 5 processes of 1 users.

The timestamps look almost related. Every several seconds for a couple minutes.
I think that has something to do with pulseaudio, but a few weeks ago I converted over to pipewire. I’ve had the problem both before and after that change and it didn’t get worse after pipewire.

/etc/default/grub has:
GRUB_CMDLINE_LINUX_DEFAULT=“module_blacklist=hid_sensor_hub nvme.noacpi=1 mitigations=off intel_pstate=passive 915.enable_psr=0”

kernel is 6.2.9

Oh Well!

Sorry to hear you’re still dealing with this. Hmm, first I’d lose mitigations=off and intel_pstate=passive. These are unneeded on our recommended distributions and mitigations=off is simply not a great idea.

Update, grub, then when it happens again.

Sounds like there are some customization made to the default installation which will make it difficult to track down what is happening.

That said, it’s not impossible for other processes to be placed in queue ahead of the touchpad driver, especially if changes were made somewhere along the line.

Still not seeing the distro involved, but based on the kernel suggested, I imagine it’s a newer release of the distro you’re using.

If it was me, these are the steps I’d take:

  • Look for a pattern of it happening with certain software open; were their changes made to the config of said software - hardware acceleration, new drives compiled, etc? Fedora and Ubuntu work reliably on 12th gen (I install them each and every day and run full time on Fedora 37, using the details in our guide).

  • If the issue is merely touchpad jumping and not other types of freezing, then this definitely feels like something is out of time. Either due to an update gone sideways or something done after the installation as a customization (input changes).

  • Give serious consideration to a clean installation of Fedora 37 or Ubuntu. These distros are used heavily internally by me and others within the company. If this is one of those distros, then a reinstall is in order as something may be off.

Wish I had a silver fix for this one, but as it is not happening on a configuration I can replicate, a fresh install would be a solid option.

If it’s happening on multiple fresh installs, then I would ask for the distro in use so we can determine what is going on.

For me, Debian Bullseye, XFCE, up to date.

Have not done any testing in Debian (any release) myself, but something that may be worth investigating is to see if the logs show anything that stands out. journalctl -f is great for this as it will show weirdness in real time. Worth a whirl.

Yes. Everyone says that - I’ve heard it so many times =-)

As an aside, I’m on Bookworm now, so I have real actual drivers and the GPU is doing it’s thing, and the issue remains, but considerably more rarely.

It is often the case, when it does happen, something kicks it off - like opening a video.

Closing and opening the lid solves the problem.

Appreciate the update. For your Debian setup, this workaround may be the best course of action.