This article describes two possible solutions to the problem of erratic mouse behaviour arising on a Tranquil T1 computer, running XFree86 under SuSE Linux 9.0, when the computer misinterprets information arriving via a KVM switch.
Please note that this article describes a problem and solutions for a computer running the X-server on SuSE Linux. There is another article that describes a possible solution for a Windows KVM/mouse problem on a desktop machine with Windows 98.
Seven computers were connected to a Belkin OmniView Matrix “F1D208-OSD” KVM (Keyboard Video Mouse) switch. Two of the computers were running SuSE Linux 8.1, two were running SuSE Linux 9.0, one was running Windows 2000, one was running Windows 98SE and one was running DOS 6.22.
Before you try a sophisticated and technical solution, don't forget that perhaps your mouse just needs a rigorous cleaning.
The single keyboard connected to the switch was a KeyTronic “lifetime” series keyboard with trackball. Problems were encountered on the computer running Windows 98 computer and on one of the computers equipped with SuSE Linux 9.0. In both cases the symptoms were similar, namely that the computer would stop processing the trackball operations correctly and the result would be that the mouse pointer would move erratically around the screen and the computer would behave as if the trackball / mouse buttons were being pressed. This was, to say the least, annoying.
This article describes a possible fix for the computer running SuSE Linux 9.0 — there is another article if you want to know about the solution for the computer running Windows 98.
The computer exhibiting the problem was a “Tranquil T1”, which is a low profile fanless machine with a VIA C3 processor and highly integrated chipset. SuSE Linux 9.0 uses the XFree86 graphics software as the base for the various desktops. In this case the KDE desktop was being used.
On this installation, the XFree86 configuration file can be found at: /etc/X11/XFree86.conf Within this configuration file is a section with parameters and options for the pointing device. The contents of this section are shown below:
Section "InputDevice" Driver "mouse" Identifier "Mouse" Option "Device" "/dev/mouse" Option "Emulate3Buttons" "on" Option "Name" "Autodetection" # Option "Protocol" "ps/2" Option "Protocol" "auto" Option "Vendor" "Sysp" EndSection
As can be seen from the commented-out line, the protocol was changed from “PS/2” to “auto”. Thereafter the mouse performed as it should.
On the GNU/Linux based machine the erratic pointer motion has only been observed arising when pressing a button to switch from one channel of the KVM to another. However the erratic motion has never been seen to occur when the KVM channel is switched using the hot key controls. For the Belkin F1D208 OmniView the channel can be changed by pressing the following hot key combination:
Scroll Lock - Scroll Lock - <bank number> - <device number>
Where device number is between 0 and 8 inclusive and bank number depends on your installation (but for a single KVM switch will always be zero). For example, to switch to the fifth machine on bank zero:
Scroll LockScroll Lock 0 5
Sometimes the Belkin OmniView 2x8 KVM gets confused about the state of the Scroll Lock key and beeps (to show that a channel change is in progress) after only one press of the key; it can be resolved by pressing some neutral key like a shift key and then pressing Scroll Lock again. It might be necessary to press the keys with a delay of a second or two in order to get the desired effect and certainly the OmniView KVM does not seem to be happy to recognize rapid key presses.
The above hot key combination works with the F1D208 which is a 2x8 matrix. If you have one of the more common KVM switches with a 1x2, 1x4 or 1x8 matrix then it is possible you can use a similar sequence but but you don't need the bank number and change channels by pressing only three keys instead of four.
A similar problem of erratic pointer movement can also occur on Windows systems and a number of people have posted information to the web concerning this. There is also an article on this web site: Windows KVM pointer problems.
Various web postings, including manufacturers' technical pages, claim that the problem occurs because of a mismatch between the mouse drivers on the systems connected to the KVM switch. This may well be true but strikes me as being a feeble excuse since a KVM switch is supposed to be transparent to the systems connected to it. It seems rather foolish, or at least unrealistically optimistic, to expect a KVM switch user to install the same operating system and drivers onto every machine just so that the KVM switch can perform its supposedly transparent task correctly. Consequently I am inclined to regard the problem as a manifestation of incompetence on the part of the KVM switch manufacturers.
Nonetheless, bearing the above mentioned explanation in mind, it might be that you will be able to improve matters with your installation by trying different drivers for your pointing devices and, if you have machines that all have the same operating system, possibly by ensuring that all machines are using standard and identical drivers for their pointing device. Again, a web search will probably provide you with useful information. Good luck!