Paranormal mouse and keyboard behavior...

Hans

Member
Joined
Nov 6, 2017
Messages
37
Reaction score
21
Credits
0
Well - maybe not really paranormal, but that sounded more fun :). Maybe more accurate to say "Mice and Keyboards Behaving Badly".

I wouldn't normally write about something like this, because, though annoying, I could remedy the problem by moving the mouse to another USB port - if one was open. But - not any more.
I'm running Linux Mint. The problem I'm having involves both of my mice (one optical and cabled, the other optical and wireless) and my keyboard. The mice become very sluggish, and skip around on the screen to the point that it is too frustrating to use until the problem is corrected. When it happens to the keyboard, the sluggish response causes typing errors unless words are typed very slowly, as in the "hunt and peck" style. The keyboard and mice do not seem to depend on how the other is acting.

When this started months ago, I found that using a different mouse got around the mouse problem. Then, when the new mouse starting behaving the same way, I found that using a different USB port would correct it. But, that is no longer working either. By the way, the behavior occurs whether I am using a USB extender, or connected directly into my Mac.

If the mice are behaving, the problem typically starts after the computer has brought up a log-in screen due to inactivity. That's when things go awry. But, moving the mouse and or keyboard to another port only helps sometimes now. The problem has even persisted through a reboot.

The hardware is from all different manufacturers, and has worked for a lot fine for years. Any suggestions?
 


Hi @Hans ... you get all the best problems, nice to work with you again, albeit you have a problem :p

At Terminal type in and enter the following:

Code:
xinput

#This is the same as for

xinput --list  #that's a double-dash

Mine looks as in the Spoiler, and I have included the use of both, and in between, how to find the manual for many commands

chris@XenialUnityStudy:~$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Lite-On Technology Corp. Wireless Device id=11 [slave pointer (2)]
⎜ ↳ Lite-On Technology Corp. Wireless Device id=12 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=15 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Power Button id=9 [slave keyboard (3)]
↳ Lite-On Technology Corp. Wireless Device id=10 [slave keyboard (3)]
↳ TOSHIBA Web Camera - HD id=13 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=14 [slave keyboard (3)]
↳ Toshiba input device id=16 [slave keyboard (3)]
chris@XenialUnityStudy:~$ man xinput
chris@XenialUnityStudy:~$ xinput --list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Lite-On Technology Corp. Wireless Device id=11 [slave pointer (2)]
⎜ ↳ Lite-On Technology Corp. Wireless Device id=12 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=15 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Power Button id=9 [slave keyboard (3)]
↳ Lite-On Technology Corp. Wireless Device id=10 [slave keyboard (3)]
↳ TOSHIBA Web Camera - HD id=13 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=14 [slave keyboard (3)]
↳ Toshiba input device id=16 [slave keyboard (3)]
chris@XenialUnityStudy:~$

If you can give us the output for xinput, that's a start.

Another question is

Do you have a touchscreen?

Cheers

Chris Turner
wizardfromoz
 
Hi @Hans... welcome back! I might have thought the problem was related to hibernation (which can be disabled)... but persisting through a reboot seems to rule that out. I'll poke around the web a bit and wait on your response to Wizard's request to see how he tackles the problem.
 
A few quick and easy things to try....

1. Unplug ALL of your USB devices except the keyboard and mouse. Test it. Looking back at your previous post with Pearl OS problems showed you had several USB drives attached, making me think this is normal for you. Also using a USB hub says you sometimes need a lot of USB connections. If your hub does not have its own power supply, you are very likely drawing too much power from the system. Even if it does have its own power supply, it could still possibly be underpowered.

2. If you have an nVidia graphics card, install the proprietary driver for it using the Linux Mint Driver Manager.

3. If your Mac is a laptop, unplug the computer's battery and run on the AC power cord only. If a desktop, never mind. A weak laptop battery can contribute to the problem I'm looking for in item #1 above.

4. When the problem is happening, open a terminal if you can and run the top command. Look for anything that shows excessive %CPU or %MEM usage. You'll have to use CNTL-C to exit from the top program when done testing.


Okay, I'll keep poking around the web too. There are a lot of reports of this kind of problem and the solutions vary. Some folks suggest modifying config files, but those kinds of things can wait while we hope for a simpler fix.

Cheers
 
A few quick and easy things to try....

1. Unplug ALL of your USB devices except the keyboard and mouse. Test it. Looking back at your previous post with Pearl OS problems showed you had several USB drives attached, making me think this is normal for you. Also using a USB hub says you sometimes need a lot of USB connections. If your hub does not have its own power supply, you are very likely drawing too much power from the system. Even if it does have its own power supply, it could still possibly be underpowered.

2. If you have an nVidia graphics card, install the proprietary driver for it using the Linux Mint Driver Manager.

3. If your Mac is a laptop, unplug the computer's battery and run on the AC power cord only. If a desktop, never mind. A weak laptop battery can contribute to the problem I'm looking for in item #1 above.

4. When the problem is happening, open a terminal if you can and run the top command. Look for anything that shows excessive %CPU or %MEM usage. You'll have to use CNTL-C to exit from the top program when done testing.


Okay, I'll keep poking around the web too. There are a lot of reports of this kind of problem and the solutions vary. Some folks suggest modifying config files, but those kinds of things can wait while we hope for a simpler fix.

Cheers


Hey guys, thanks for the welcome back : )

Here is the result of the “xinput” command:

~ $ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ TypeMatrix.com USB Keyboard id=12 [slave pointer (2)]
⎜ ↳ Macally Peripherals Macally USB Optical Net Mouse id=9 [slave pointer (2)]
⎜ ↳ Microsoft Microsoft Notebook Receiver v2.0 id=14 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ Apple Computer, Inc. IR Receiver id=10 [slave keyboard (3)]
↳ TypeMatrix.com USB Keyboard id=11 [slave keyboard (3)]
↳ TypeMatrix.com USB Keyboard id=13 [slave keyboard (3)]

When I ran this, the problem was active.

Not using a touchscreen...

Next, I checked the USB devices and here was the state they were in:

Only the keyboard and the two mice were connected. They were connected directly to the Mac mini computer, and not in a USB extender. No other USB devices were connected (there are 5 USB ports in my Mac), which is a desktop computer.

When I ran the "top" command:
Web Content ~75 % CPU
Firefox was taking up ~15% CPU
The rest were in single digits.
I closed firefox, but the problem persisted.

Video driver
Hardware shows that I have an NVIDIA C79 GeForce 9400 graphics card
The Driver Manager shows I am using:
nvidia-340 (recommended)
Version 340.102-Oubuntu0.16.04.2
NVIDIA binary driver - version 340.102

Thanks again, I appreciate the help!
 
Hi Hans and you are always welcome :D

Thanks for the output, had there been a touchscreen involved, I would have followed a certain course.

I'd like to see what Stan thinks about the outcomes to his questions.

Now, you had changed from Pearl 6.0 to a "Mintie", hadn't you? Is that so on this desktop?

If so, can you tell us which Mint and which DE (Desktop Environment) for example - Linux Mint 18.3 Cinnamon.

With the xinput output (that sounds funny), I find the lines

TypeMatrix.com USB Keyboard id=

unusual for having three references, instead of two. I think there should be only one at the bottom, not two.

Identifying and removing a surplus line might fix the keyboard issue, and we would do that with the use of

Code:
xinput disable <id no. of device.>

.. which would only apply for the session you are in, but a permanent fix can be applied.

I have to fly, but we can look at these possibilities more if needed, and Stan will look after you.

Also, @Hans - with those 5 USB ports, are they USB2.0 or 3.0 or a combination and if so, which is the cabled mouse using, and are the mice USB 2.0 or 3.0?

Cheers

Wizard
 
I'm still looking. Some things are too difficult or uncertain to just try on a whim, so I'm still looking for the simpler possibilities.

Like Wizard, I'm curious if you're using Cinnamon or Mate? I seem to find more problems with Cinnamon. If you're using Cinnamon, can you burn a DVD/USB with Mate to test that in live mode?

Also, the question of ports, whether USB2 or USB3 capability. I would suggest using only USB2 ports if there is a difference on the Mac, regardless of whether the mouse/keyboard is USB3 capable. (I'm sure you can't type fast enough to take advantage of the increased USB3 speeds! :D)

Gotta go plow some snow. Silly winter here... but I guess it's been HOT down under for Wizard!

Cheers
 
I know...we got some snow too.
Looks like I'm running Linux Mint 18.3 'Sylvia' Cinnamon.
All my ports are USB 2.0.
I will try to get ahold of Mint Mate and get it onto a USB.
Still working with disabling some of the surplus lines in xinput.
Thanks Guys!
 
Hi @Hans

This may be stating the bleeding obvious, but for the benefit of The Viewers:

If you are going to disable your keyboard, then obviously you might need something to allow you to enter alphanumeric input, whether to reverse the process, or to perform other commands? That is where the virtual keyboard comes in.

In Hans' LM 18.3 'Sylvia' Cinnamon, he can go to Menu-All Applications-Accessibility, press the Keyboard tab, and under Virtual Keyboard, change the option "Enable the on-screen keyboard" from its default OFF to ON, and the virtual keyboard will appear. You can then for example open your Terminal (Ctrl-Alt-t in many Debian-based distros), enter text or numerals using your mouse and work that way.

To switch off the virtual keyboard, top right-hand side of the keyboard, in this case, there is an icon of a keyboard, click it and the keyboard disappears.

If you try and like this feature, having enabled it survives a logout or reboot, but I haven't found, in this Cinnamon, a shortcut combination to make the keyboard reappear after you have closed it down using that little icon.

You can, however, assign your own custom shortcuts, by going through Settings-Keyboard-Shortcuts (-Universal Access), and set up a custom shortcut of your choice. No need to actually choose Custom Shortcuts, just choose Universal Access - turn on-screen keyboard on or off, then click the first "binding" below that list and type in your shortcut keys of choice. I've used Ctrl-Alt-K. If you ever need to know the command file, it is /usr/bin/onboard.

Back to Hans' dilemma:

Those bottom two lines from your output were

↳ TypeMatrix.com USB Keyboard id=11 [slave keyboard (3)]
↳ TypeMatrix.com USB Keyboard id=13 [slave keyboard (3)]

In many cases if you are disabling a device, and you want to incorporate it into a script to run, it is advisable to use the full name of the device. This is because assignment of numeric IDs may change with introducing a new device and removing another. Use double quotes.

So

Code:
xinput disable 11

# is the same as

xinput disable "TypeMatrix.com USB Keyboard"

Here, though we have two descriptions the same, so best to use the numbers.

Try xinput disable 11, and see if it fixes your keyboard (changes take place in real time), if not, first re-enable it with xinput enable 11, then repeat the process with xinput disable 13.

If one of these works, we are looking good.Changes effected using xinput in this way affect only the current session and do not survive a logout or reboot. You would have to repeat the process each time you fired up your computer, but if we can find that id 11 or id 13 is the troublemaker, we can write into a file called rc.local to perform this at startup, or we can take a look at a file in /usr/share/X11/xorg.conf.d/, or other means, to make the changes stick.

Cheers and keep smiling :p

Wizard
 
Hi @Hans

This may be stating the bleeding obvious, but for the benefit of The Viewers:

If you are going to disable your keyboard, then obviously you might need something to allow you to enter alphanumeric input, whether to reverse the process, or to perform other commands? That is where the virtual keyboard comes in.

In Hans' LM 18.3 'Sylvia' Cinnamon, he can go to Menu-All Applications-Accessibility, press the Keyboard tab, and under Virtual Keyboard, change the option "Enable the on-screen keyboard" from its default OFF to ON, and the virtual keyboard will appear. You can then for example open your Terminal (Ctrl-Alt-t in many Debian-based distros), enter text or numerals using your mouse and work that way.

To switch off the virtual keyboard, top right-hand side of the keyboard, in this case, there is an icon of a keyboard, click it and the keyboard disappears.

If you try and like this feature, having enabled it survives a logout or reboot, but I haven't found, in this Cinnamon, a shortcut combination to make the keyboard reappear after you have closed it down using that little icon.

You can, however, assign your own custom shortcuts, by going through Settings-Keyboard-Shortcuts (-Universal Access), and set up a custom shortcut of your choice. No need to actually choose Custom Shortcuts, just choose Universal Access - turn on-screen keyboard on or off, then click the first "binding" below that list and type in your shortcut keys of choice. I've used Ctrl-Alt-K. If you ever need to know the command file, it is /usr/bin/onboard.

Back to Hans' dilemma:

Those bottom two lines from your output were

↳ TypeMatrix.com USB Keyboard id=11 [slave keyboard (3)]
↳ TypeMatrix.com USB Keyboard id=13 [slave keyboard (3)]

In many cases if you are disabling a device, and you want to incorporate it into a script to run, it is advisable to use the full name of the device. This is because assignment of numeric IDs may change with introducing a new device and removing another. Use double quotes.

So

Code:
xinput disable 11

# is the same as

xinput disable "TypeMatrix.com USB Keyboard"

Here, though we have two descriptions the same, so best to use the numbers.

Try xinput disable 11, and see if it fixes your keyboard (changes take place in real time), if not, first re-enable it with xinput enable 11, then repeat the process with xinput disable 13.

If one of these works, we are looking good.Changes effected using xinput in this way affect only the current session and do not survive a logout or reboot. You would have to repeat the process each time you fired up your computer, but if we can find that id 11 or id 13 is the troublemaker, we can write into a file called rc.local to perform this at startup, or we can take a look at a file in /usr/share/X11/xorg.conf.d/, or other means, to make the changes stick.

Cheers and keep smiling :p

Wizard
Thank you Wizard - I tried deleting one of the mouse entries first. It stopped responding, so I just disconnected it and and reconnected it to the same port. It has been working fine now for 2 days, even after the machine comes out of some kind of sleep mode.
Next, I tried the same thing with the keyboard - with the same happy outcome : ) You might have fixed this frustrating problem! If you are willing to share the commands that can make it permanent, I would like to have those on-hand in case this fix endures so it survives reboots, as you mentioned.

I appreciate all the help guys - this seems like such a little thing, but it was really frustrating to me. Thanks!
 
That's great news, @Hans , hope it persists :D

If you are willing to share the commands that can make it permanent,

The Linux Community is all about sharing, it is the credo of FOSS (Free and Open Source Software) :)

I will cobble together some options, and be back here when I can.

Good luck, and enjoy your Linux

Wizard
 


Top