You are not logged in.
Pretty sure the usb2 ports are controlled by xhci as well?
lsmod | grep -i hci
lsusb -tvYou could try to blacklist xhci-hcd (but will likely lose access to all usb-3 ports) and enforce ehci.
https://wiki.archlinux.org/title/Kernel … acklisting
Add "module_blacklist=xhci-hcd" to the kernel parameters. Do so from the bootloader (grub?) commandine to have it transient. Otherwise you might find yourself having to use some live distro to restore any input device functionality if things go wrong.
Offline
Yeah i thought about that too. But losing all USB3 Ports would be a bad solution i guess. I might just connect the Keyboard to an USB3 Port (since it at least then doesn't get "stuck" anymore still find it odd that this happens on USB2 but not on 3). Though the issue somewhat remains even then and evetest then will still get spamed with these non-release events but at least other input is still detecte which is better than the need of disconnecting the keyboard manually each time i accidently press the wrong combo lol.
Last edited by Oddwierdo (2023-08-04 07:52:34)
Offline
Not as solution but to figure whether it's because of xhci-hcd
Offline
it doesn't seem to work to actually disable xhci-hcd this way. I just tried it but it still seems to be active after reboot. I also checked
lsmod | grep xhciand the only modules appearing are xhci_pci
Offline
xhci_hcd is built-in
You can also block xhci_pci and see "lspci -k" for which module(s) are actually used on the hub.
Offline