Hi there,
I have a strange problem with wireless/wired USB mice and keyboards. I bought a Logitech MK330 mouse/keyboard combo and when I insert the receiver in any usb on my laptop the mouse works for a few seconds and then stops. I thought it may be the Logitech device broken, so I bought a cheap wired mouse, but the problem is the same. The laptop is ASUS FX705D, I made a clean install via USB flash drive of openSUSE 15.3 and upgraded to 15.4 via the console. Never had such kind of issue before. Please help me to handle this.
You made a clean install and upgrade after discovering the USB problem, and the problem continued in 15.3 and 15.4, or before?
Is the problem the same whether or not you cold boot with the receiver or mouse plugged in?
I had a problem like this a couple of months ago it disappeared after a couple of new snapshot in tumbleweed.
Then it happened again two weeks ago but didn’t bother to tried searching for a clue or solution, after some zypper dup lately it is
normal again. The one that works for me was using pressing
Ctrl-Alt-F1 then Ctrl-Alt-F7
to make my mouse run smooth again
You can google
sleeping usb mouse in linux
you might find some interesting topic regarding your case
I am experiencing the same keyboard/mouse issues with Leap 15.4, fresh install and fully updated. I also switched from wireless mouse/keyboard to wired, it made no difference.
> uname -a
Linux 5.14.21-150400.24.11-default #1 SMP PREEMPT_DYNAMIC Sun Jul 17 20:46:33 UTC 2022 (be260ca) x86_64 x86_64 x86_64 GNU/Linux
Mouse clicks and keyboard input will occasionally get ignored, become sluggish and even non-resposive. There are also some strange behaviors. For example, open Files, then click Home in the top bar, instead of getting a drop-down box the Files window shifts position on the desktop.
When running graphics/multimedia intense apps the mouse and keyboard functionality becomes very erratic to non-useable. Using Firefox is a supreme PITA as is Blender and so on. The problem can readily be reproduced running multiple graphics/multimedia apps concurrently. For example, start Firefox, navigate to a streaming website and play a video. Concurrently, run gzdoom with freedoom wad and the mouse/keyboard issues arise quite quickly. Similarly, play a video with VLC media player while running gzdoom with freedoom wad, again the mouse/keyboard become virtually unuseable. Or run Blender and VLC media player concurrently, same issue. Too, simple apps alone like gedit get tedious with recurring mouse/keboard issues during a session. There is clearly some low-level problem with 15.4.
Leap 15.3, Archlinux, Fedora 36 and Ubuntu 22.04 all run with no mouse/keyboard issues on the EXACT SAME HARDWARE PLAFORM as the wonky Leap 15.4. I ain’t the hardware folks.
When a new system release occurs, I install it on one system then check it out to learn the new quirks and bugs. Then, when the previous release reaches end-of-life my other systems are then migrated to the new release. Saves a lot of headache. At this time, Leap 15.4 is unuseable. Hopefully an update will show up to fix the mouse/keyboard issue (and others) before end-of-life for Leap 15.3. In the meantime the Leap 15.3 systems are working just fine.
Graphics-related behaviour perhaps? Let’s get some hardware info…
inxi -SMCGa
Greets,
Graphics related? Possibly from a software standpoint, not hardware. As I noted in my previous post, other linux distros as well as Leap 15.3 work fine on exactly the same machine, Leap 15.4 is the problem. Also, the original poster of this thread is using a laptop where I am using a destop, very different hardware critters. If you are familiar with hard real-time operating systems, the mouse/keyboard behavior “feels” very much like an overloaded real-time os. The more task load on the system, the more noticeable the mouse/keyboard quirks. Certainly graphic/multimedia/games put a significant load on the system so provides a means to replicate and demonstrate the mouse/keyboard issue in short order. The are also other quirks, most notable in the GUI. Clicking a widget will randomly do something other than what the widget is suppose to do. As I mentioned I my previous post, this appears to be a low level software issue. It would not at all be suprising that the cause turns out to be a regression unrelated to keyboard/mouse or that the issue simply disappears in a future software update.
Anyhow, it never hurts to explore anomalous issues so here’s inxi…
> inxi -SMCGa
System:
Host: cylon Kernel: 5.14.21-150400.24.11-default x86_64 bits: 64
compiler: gcc v: 7.5.0
parameters: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150400.24.11-default
root=UUID=b1db876f-a467-402c-a6dd-19bd191f626f splash=silent
resume=/dev/disk/by-uuid/707f38be-b71e-4e0f-bee2-7d0817832bf1 preempt=full
mitigations=auto quiet security=apparmor
Desktop: GNOME 41.4 tk: GTK 3.24.31 wm: gnome-shell dm: GDM 41.3
Distro: openSUSE Leap 15.4
Machine:
Type: Desktop Mobo: ASUSTeK model: PRIME X570-PRO v: Rev X.0x
serial: <superuser required> UEFI: American Megatrends v: 4204
date: 02/24/2022
CPU:
Info: 8-Core model: AMD Ryzen 7 5800X bits: 64 type: MT MCP arch: Zen 3
family: 19 (25) model-id: 21 (33) stepping: 2 microcode: A201205 cache:
L2: 4 MiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
bogomips: 134408
Speed: 4187 MHz min/max: 2200/4200 MHz boost: disabled Core speeds (MHz):
1: 4187 2: 4198 3: 4193 4: 4178 5: 4232 6: 4215 7: 4182 8: 4200 9: 4169
10: 4199 11: 4212 12: 4197 13: 4196 14: 4197 15: 4199 16: 4161
Vulnerabilities: Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: mmio_stale_data status: Not affected
Type: retbleed status: Not affected
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl and seccomp
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, IBRS_FW,
STIBP: always-on, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Graphics:
Device-1: AMD Navi 24 [Radeon RX 6400 / 6500 XT] vendor: Tul
driver: amdgpu v: kernel bus-ID: 0a:00.0 chip-ID: 1002:743f class-ID: 0300
Display: wayland server: X.org 1.20.3 compositor: gnome-shell driver:
loaded: amdgpu note: n/a (using device driver) - try sudo/root
display-ID: 0 resolution: <missing: xdpyinfo>
OpenGL: renderer: AMD BEIGE_GOBY (DRM 3.42.0 5.14.21-150400.24.11-default
LLVM 11.0.1)
v: 4.6 Mesa 21.2.4 direct render: Yes
Ok, thanks for posting the info. It caught my interest because I found several threads including this one…
https://askubuntu.com/questions/1195686/mouse-randomly-stops-responding-for-a-few-seconds
where AMD Ryzen and AMD graphics were in use. In particular, see if adding the ‘amd_iommu=off’ kernel boot parameter is helpful to your situation.
Quite likely 
Is behavior the same if you:
- login as brand new virgin user?]run Gnome in X11 instead of Wayland?]boot without preempt=full?]run some X session other than Gnome?]configure X to use modesetting DIX instead of amdgpu DDX[1]
[1] Either create a file /etc/X11/xorg.conf.d/15-ddxdrv.conf containing:
Section "Device"
Identifier "DDX"
Driver "modesetting"
EndSection
or remove DDX package xf86-video-amdgpu.
Good stuff! KDE is also affected. See the bugzillas I referenced.
Got a kernel update today. Was hoping the keyboard/mouse lag and lockup would be fixed. Nope. Actually worse. Takes nothing more than running the gnome text editor to trigger abberant behavior. Anyone else?
> uname -a
Linux cylon 5.14.21-150400.24.18-default #1 SMP PREEMPT_DYNAMIC Thu Aug 4 14:17:48 UTC 2022 (e9f7bfc) x86_64 x86_64 x86_64 GNU/Linux
Perhaps try using the current stable kernel?
As described here…
https://forums.opensuse.org/showthread.php/569539-touchpad-does-not-work-on-laptop?p=3124933#post3124933