Qubes R4.2.2 sys-usb mouse works, but can't click, no keyboard

Problem:
my Qubes workstation after a random period of time will stop accepting mouse clicks. This occurs after using the keyboard or mouse to wake the computer/monitor from sleep (works), xscreensaver asks me to unlock with my password (works) but then once unlocked, the mouse pointer moves but I can’t click anything regardless of appvm, including changing focus, right click on desktop, menu etc. Nor does the keyboard input work, caps lock and numlock keys light the corresponding LED, and I’m able to press a key to get the screen to wake up, but alt tab, does not work. The only key combos that work at all are Ctrl + Alt + F7, F1. At this point the only thing I can do is to power off and reboot, after which everything is normal until the next time the problem occurs.

Config:

  • Qubes R4.2.2
  • Sys-usb disposable (so, no logs I can refer to after the crash)
  • keyboard + mouse are usb obviously
  • kernel 6.6.36-1 dom0
  • kernel 6.6.36-1.qubes.fc37.x86_64 (sys-usb)
  • everything up to date with

As I can’t replicate the problem on demand, I’m testing with qubes.skip_autostart and no sys-usb to see if the problem persists in order to eliminate sys-usb as the issue. If that doesn’t change anything I’ll start rolling back updates on the dvm template and dom0 till I figure out what caused it.

Question:
Has anyone else encountered this, got a fix? I’ve not had much luck searching as most people’s sys-usb issues are config related. Any ideas how else I can get additional info on what’s happening would be EXTREMELY useful. My working theory right now is that sys-usb disk and logs fill, but I can’t prove that yet.

ty!

1 Like

This sounds like a Xorg issue in dom0 after suspend/resume. A Xorg soft lock would look like this, a moving cursor but not interaction with the desktop, I already had this a few times but never on Qubes OS.

If you can use CTRL+ALT+F2 to switch to a tty, log in into your user, try systemctl restart lightdm to restart X and the display manager.

4 Likes

@solene back again with the fix! TYSM! This worked for me do you any idea on how to prevent it happening again?

1 Like

This should not happen in the first place. Maybe your graphics card is not well supported.

1 Like

I dont have a discreet GPU, just the integrated GPU on the ultra 7 155h. It’s a Qubes certified v56 from novacustoms

1 Like

When I said graphics card, this also count for integrated GPU :wink:

Does it happen often? Check if your laptop has a firmware update maybe? Are you using latest kernel?

2 Likes

Just to add I still encounter this issue, but very rarely, always after the system is idle for a prolonged period with some combination of the screens being powered off, my hardware KVM switched away from Qubes then switched back. I’ve the following hardware:

XX:XX.X VGA compatible controller: NVIDIA Corporation GA104 [GeForce RTX 3060 Ti Lite Hash Rate] (rev a1)
XX:XX.X VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 980] (rev a1)

When I say “switched away” I mean to either an HVM with dedicated GPU (3060) + pci-e USB controller (the KVM is connected to both dom0 and the HVM), or to an entirely separate/physical PC.

With dom0 running on the 980. Whenever I encounter this I use Solene’s solution. I’ve now upgraded to Qubes R4.2.3 / kernel 6.6.68-1 and will momentarily be upgrading to Qubes R4.2.4.

I can’t replicate this at will unfortunately, so very difficult to troubleshoot further unless anyone has any ideas?

1 Like

Are you using nouveau or nvidia driver in dom0? In both cases, I’d bet it’s the driver for the GPU that is making troubles with suspend/resume.

1 Like

dom0 is using nouveau, I did investigate switching the new open drivers, but wanted to wait till a dom0 fedora version bumps before I invest in setting up a build environment. I unfortunately have no AMD cards to test if that changes things.

1 Like

the official open source drivers are only compatible with newer GPU (1650 and 2xxx)

2 Likes