Linux GUI/Input Freeze – Complete Troubleshooting Summary

Help
, ,
1

System

Hardware

  • CachyOS (Arch Linux)

  • KDE Plasma 6

  • Plasma Login Manager (not SDDM)

  • NVIDIA RTX 5060 Ti (8 GB)

  • NVIDIA Open Driver 610.43.02 (nvidia-open)

  • AMD Ryzen CPU

  • Lenovo Legion T5 OEM motherboard

  • New GPU and new PSU

  • Same CPU, RAM and motherboard as before

Displays

The Linux PC is connected to:

  • DisplayPort → external monitor

  • HDMI → Lytmi Fantasy 3 HDMI 2.1 Sync Box → LG C3 OLED

Problem

The desktop randomly enters a state where:

  • Mouse cursor continues moving normally.

  • Keyboard continues working.

  • The graphical desktop stops responding correctly to mouse clicks.

  • The system appears “frozen”, but it is not actually locked up.

The issue occurs:

  • After logging in.

  • During normal desktop use.

  • After the system has been idle.

  • There is no obvious trigger.

Recovery

Switching to a TTY:

Ctrl+Alt+F3

then switching back to Plasma

always restores the desktop immediately.

No reboot is required.

This recovery method works every time.

What has already been tested

Display server

  • Wayland → same issue.

  • X11 → same issue.

Kernel

  • Standard CachyOS kernel → same issue.

  • CachyOS LTS kernel → same issue.

Btrfs

Disabled Btrfs quotas.

No improvement.

CachyOS-specific packages

Removed:

  • cachyos-settings

No improvement.

DDC / Power Management

Originally Powerdevil repeatedly logged:

Open failed for /dev/i2c-X

I completely removed ddcutil.

No improvement.

Mouse

Tested with a completely different wired mouse.

Same issue.

This strongly suggests the problem is not caused by the SteelSeries mouse.

Temperature

CPU and GPU temperatures are normal.

No indication of overheating.

Display hardware testing

The Linux PC normally outputs to:

  • DisplayPort monitor

  • HDMI → Lytmi → LG C3

I completely disconnected power from the Lytmi box.

The system continued running only on the DisplayPort monitor.

The issue still occurred.

This strongly suggests that neither the LG C3 nor the Lytmi box is the root cause of the Linux issue.

Things that are effectively ruled out

  • Wayland

  • X11

  • Kernel version

  • Btrfs quotas

  • ddcutil

  • Powerdevil

  • cachyos-settings

  • Mouse hardware

  • Temperature / overheating

  • LG C3 as the sole cause

  • Lytmi as the sole cause

Remaining observations

The issue appears to affect the desktop/input state rather than the entire operating system because:

  • Mouse movement continues.

  • Keyboard continues working.

  • Switching to another virtual terminal (TTY) and back immediately restores normal operation.

This suggests that something in the graphical session is entering an invalid state.

Current hypotheses

At this point, the most likely remaining possibilities are:

  1. NVIDIA Open Driver (nvidia-open) regression or DRM/KMS issue.

  2. KDE Plasma / KWin compositor bug.

  3. Input/focus/compositor state becoming invalid.

  4. Hardware instability (RAM) — considered less likely because the system recovers instantly by switching TTYs, but not yet ruled out.

Questions

  1. Based on everything above, what is the most likely root cause?

  2. Is this a known KDE Plasma, KWin or NVIDIA DRM issue?

  3. Does the fact that switching to a TTY and back always fixes the problem point toward a specific subsystem?

  4. Given everything already tested, what would you investigate next?

Please avoid suggesting the following, as they have already been tested:

  • Switching between Wayland and X11

  • Different kernels

  • Removing ddcutil

  • Disabling Btrfs quotas

  • Removing cachyos-settings

  • Trying another mouse

  • Disconnecting the Lytmi box

  • Disabling TV-related features (CEC, VRR, Deep Color, etc.)

2

Hi, sorry to see you have such a strange problem. You have tested already a great deal!

I have never encountered this particular problem, so the first thing that I would try next is to try either a different desktop (gnome, XFCE) and log into that with a new and fresh user account (just to avoid any trouble that may come through switching desktops, this is rare but possible), see if the problems are similar there. Alternatively I would try plasma beta.

If the problem is also on X11 that to me would be an indicator that perhaps trying only a fresh user account and the SAME desktop may also be interesting to compare.

Let’s hope it is something that is easily fixed…

3

hi, welcome.

very detailed post, congrats.

the first thing i always do when it comes to nvidia cards is to go to their official website and look up which driver should be used with the given product.

since you specified the RTX 5060 Ti, when i look that up it shows you should be using the driver Linux x64 (AMD64/EM64T) Display Driver 595.84 | Linux 64-bit

instead of the one you are using.

it’s not a matter of the highest version number available, it’s a matter of which driver is recommended for that particular hardware and nivida knows this better than anyone.

4

Major update: this also happens on Windows — I’ve been troubleshooting the wrong layer

I need to correct a key assumption from my original post. Since writing it, I’ve found that a very similar freeze also happens on Windows, not just Linux. That reframes everything, because it means the root cause almost certainly isn’t Plasma, KWin, nvidia-open, or the kernel — none of those exist on both operating systems.

The reason I missed the connection for so long is that the trigger is different on each OS:

  • On Windows: the freeze is triggered when I switch my mouse between 2.4 GHz (USB dongle) and Bluetooth and back. It’s tied to the wireless mode switch, not to anything graphical.
  • On Linux: the trigger is inactivity. I don’t log out or switch anything — if I’m simply logged in and don’t touch the mouse for some minutes, the desktop enters the frozen input state I described. It’s idle-related here, not tied to the mouse mode switch.

So it’s the same class of failure on both systems — input entering a frozen state that recovers instantly — but provoked by different events (wireless mode switch on Windows, idle timeout on Linux).

Relevant hardware context:

  • The wireless side involves a MediaTek MT7921 WiFi/Bluetooth combo module (visible in my logs), plus a wireless mouse used in both 2.4 GHz and Bluetooth modes.
  • Important: on Linux the freeze also happens with a wired USB mouse, so it isn’t the wireless link itself dropping. Combined with the Windows trigger being a wireless mode switch, this makes me suspect the shared factor is the USB / input subsystem or its power management, rather than any specific mouse or wireless mode.
  • On Linux, switching to a TTY and back restores input every time, no reboot needed. I’m no longer sure whether that points at software or hardware, but it does show the input pipeline can be knocked into a bad state and re-initialised on the fly.

Updated questions, given this is now confirmed OS-independent:

  1. Does an input freeze that occurs on both Windows and Linux — triggered by a wireless mouse mode switch on one, and by idle timeout on the other — point to a specific hardware or firmware layer, e.g. USB power management, PCIe ASPM, the MT7921 module, or the OEM board’s BIOS/firmware?
  2. Has anyone seen USB or wireless power-saving (autosuspend / selective suspend) cause this kind of cross-OS input hang?
  3. Given it’s not OS-specific, what would you check first — BIOS settings, a firmware update, or something else?

Apologies if this has now drifted outside KDE’s scope — since it reproduces on Windows too, it’s clearly not a Plasma issue. But if anyone recognises this pattern or can point me to the right place to look, I’d really appreciate it.

5

Important clarification: the Windows machine is a separate computer

I should make one thing clear, because it changes how to read the above: the Windows machine where I see the mouse-switch freeze is a completely separate computer — a laptop — not the same PC dual-booting. So this isn’t shared hardware between the two OSes at all.

That actually narrows things down rather than widening them. Since it’s two physically different machines, the only common factor between the Windows freeze and the Linux freeze is the mouse itself and how it switches between 2.4 GHz and Bluetooth. The two systems otherwise share no hardware.

So the picture now is:

  • Laptop (Windows): freezes when the mouse switches wireless mode (2.4 GHz ↔ Bluetooth).
  • Desktop (Linux): freezes on idle — but also froze with a wired mouse, so on the Linux side it may be a separate issue that only looks similar, rather than the same root cause.

I want to be honest that these might be two different problems that superficially resemble each other (both are “input freezes that recover”), rather than one shared cause. The mouse’s wireless-mode switching is the strongest link on the Windows laptop; the Linux desktop freeze happening even on a wired mouse suggests its cause may lie elsewhere (USB/input power management on that specific machine).

Given that, I’d narrow my questions to:

  1. On the Windows laptop, could the mouse’s own firmware or its wireless-mode switching realistically hang the whole input stack? Is this a known issue with mode-switching wireless mice?
  2. On the Linux desktop, treating it as potentially separate: does an idle-triggered input freeze that also occurs with a wired mouse point to USB autosuspend or input power management on that machine specifically?
6

for the linux box - can you tail journalctl or dmesg when it happens, anything looks like a suspect? Can you put it into performance mode to rule out some aggressive power saving kicking in? Maybe even it’s a BIOS/UEFI configured power saving.

7

two different machines running two different OS but sharing a mouse?

do they also share the monitors?

monitor cables

do you have a cat?

8

Good questions. Yes. Two different machines running two different OSes, but I share peripherals between them.

The Windows machine is my work laptop, and my setup is: I plug in the HDMI cable and switch my mouse and keyboard from their 2.4 GHz dongles to Bluetooth to move them over to the laptop, then switch back to 2.4 GHz for the Linux desktop.

So the shared hardware between the two machines is:

  • Mouse (used in both 2.4 GHz (Linux) and Bluetooth (windows) modes)
  • Keyboard — a Keychron K4 Max, same 2.4 GHz (Linux) / Bluetooth (windows) switching setup
  • HDMI cable / monitor input. HDMI 1 > Linux, HDMI 2 > Windows.
9

Cat died, so no cat..

10

sorry your cat died.

good cat?

if it was a DP cable, i was going to suggest trying a different cable (not all DP cables meet the spec)… but it might be worth trying even with an HDMI cable.

otherwise i think it just a weirdity from live swapping of these peripherals that is something you are going to have a hard time tracking down.

11

SOLVED — and it was the mouse all along.

After a HUGE amount of troubleshooting, I finally found the root cause, and it’s not what any of us expected: my SteelSeries Rival 3 Wireless Gen 2 was the culprit — and not just for its own input.

Here’s how I nailed it down.

I captured libinput debug-events during one of the freezes. When I clicked left, libinput registered both BTN_LEFT and BTN_MIDDLE pressed in the same millisecond — a ghost middle-click that never released cleanly. That invalid, stuck button state is what was locking up input handling and making the desktop look “frozen” while the cursor still moved.

But the decisive test came next. I plugged in a completely different mouse (a Logitech MX Master 3):

  • With the SteelSeries mouse powered ON, the MX Master 3 also stopped working — the whole pointer input layer was locked.
  • The moment I powered the SteelSeries OFF, the MX Master 3 worked perfectly and immediately.

So the Rival 3 wasn’t just failing on its own — while active, it was taking down the entire pointer input stack, which is why a second, healthy mouse didn’t work either. This finally explains why nothing OS-side ever helped: it was never the OS.

This also explains every symptom that confused me:

  • Froze regardless of kernel, driver, X11 vs Wayland, or theme — the mouse interferes underneath all of that.
  • The “wired mouse still froze” test was contaminated — the SteelSeries was still powered on during it.
  • TTY-switch recovery worked because it reset the pointer state, until the mouse locked it again.
  • The same freeze happened on a separate Windows laptop when switching this mouse between 2.4 GHz and Bluetooth — because it’s the mouse’s firmware, not the machine.

Root cause: defective SteelSeries Rival 3 Wireless Gen 2 emitting a stuck/ghost BTN_MIDDLE that locks up all pointer input while the mouse is active.

Fix: stop using that mouse. I’ve switched to the MX Master 3 and the freezes are completely gone. I’m going to try a firmware update via SteelSeries GG as a last resort, but I’ll likely just RMA the mouse.

Huge thanks to everyone who chimed in. Posting this in full in case someone else hits the same baffling “desktop input freeze” pattern — check whether a wireless mouse is poisoning the input stack before you spend days/weeks/months on drivers and compositors like I did.

12

Strange cause you said you tested it with a different mouse. Anyways, glad it worked out for you.

13

Yes, but the issue was that somehow my steelseries mouse interfered with the input signal from the other mouses while it was still connected. I never turned it off, but when i turned the steelseries mouse off, the freezing disappeared