Linux and KVM switches!

Linux and KVM switches!

Post by Tim Smit » Sat, 22 Feb 2003 22:48:32



A lot of people have trouble with wheel mice on Linux when they use
a KVM switch.  These are the most common two problems:

1. When you switch to Linux, the wheel does not fully work.  E.g., on mine
at work, it can scroll down but not up.

2. Moving the mouse causes the cursor to jump wildly, and also makes it act
as if buttons are being rapidly pressed.  The result is that you often
launch many things from you launch panel thingy.

Here is what is odd about this problem.

1. It doesn't seem to be a problem with the mice or KVMs, because they don't
have this problem with Windows or Mac.

2. It doesn't seem to happen all the time.  E.g., at home, I have WinXP Pro
and Linux on a 2 port Belkin SOHO switch.  I have no problem, other than
sometimes the mouse sensitivity changes under Linux.  I never lose the wheel
or get the eratic behaviour.  At work, however, with WinXP Pro, Linux (same
distribution), and OS X on a 4 port Belkin, I lose half the wheel almost all
the time, and get the erratic behavior half the time.

Some people report that if they have an unused port on their KVM, switching
to Linux, then switching to the unused port, then back to Linux, is more
reliable.  What I've found on my work system is that if I use ALT-Fn to get
out of X before switching away, and then when coming back, switch to Linux,
move the mouse, switch away, switch back, move the mouse again, and then hit
F7 to go back to X, I'm OK.

That's quite a hassle!  I did some Googling today, and saw a post on some
web discussion board from someone who talked about the character sequences
that are sent to the mouse to configure it.  Based on what he said, I offer
the following program, which fixes my mouse on Linux at work!

int main( void )
{
    char c[2] = { 255, 255 };
    int fd = open( "/dev/mouse", 1 );
    if ( fd >= 0 )
    {
        write( fd, c, 2 );
        close( fd );
    }
    return 0;

Quote:}

If I switch back to Linux, and there is any mouse problem, I run that as
root, and the problem is fixed.

So, if you have a KVM and are having Linux mouse problems, try taking that
code, putting it an file, say "fixmouse.c", and compiling (gcc -o fixmouse
fixmouse.c).  Put fixmouse somewhere in your path, and become root, and do
this from wherever you put it:

        chmod root fixmouse
        chmod 4555 fixmouse

If you are using a window manager that lets you assign hotkeys to run
programs, assign a hotkey to run fixmouse, and hit that hotkey whenever you
switch back to Linux.

If your distribution does not link /dev/mouse to whatever your mouse device
is, change the open() call to open whatever your mouse device is.

Now...if someone could tell me *why* this isn't needed in Windows and OS X,
I'll be fully happy.

--
Evidence Eliminator is worthless: "www.evidence-eliminator-sucks.com"
--Tim Smith

 
 
 

Linux and KVM switches!

Post by Erik Funkenbusc » Sun, 23 Feb 2003 01:10:01



potato.com says...

Quote:> A lot of people have trouble with wheel mice on Linux when they use
> a KVM switch.  These are the most common two problems:

Ahh.. yes, i've talked about this problem in here several times.  Of
course the usual response I get is denial of the problem, or claiming
that it's the fault of the KVM.

Quote:> 1. When you switch to Linux, the wheel does not fully work.  E.g., on mine
> at work, it can scroll down but not up.

> 2. Moving the mouse causes the cursor to jump wildly, and also makes it act
> as if buttons are being rapidly pressed.  The result is that you often
> launch many things from you launch panel thingy.

> Here is what is odd about this problem.

> 1. It doesn't seem to be a problem with the mice or KVMs, because they don't
> have this problem with Windows or Mac.

> 2. It doesn't seem to happen all the time.  E.g., at home, I have WinXP Pro
> and Linux on a 2 port Belkin SOHO switch.  I have no problem, other than
> sometimes the mouse sensitivity changes under Linux.  I never lose the wheel
> or get the eratic behaviour.  At work, however, with WinXP Pro, Linux (same
> distribution), and OS X on a 4 port Belkin, I lose half the wheel almost all
> the time, and get the erratic behavior half the time.

On my system, the KVM works fine if i'm using PS/2 mode, but flakes out
if i'm using IMPS/2.  Could it be that your wheel mouse at home doesn't
use IMPS/2, but emulates it some other way?

I've done some research on this as well, and it appears to be an XFree86
problem, not anything specific to Linux itself (though it's in effect a
Linux problem because Linux uses XFree86).  I've seen the same thing on
FreeBSD.

I've spoken with the current mousedev.c maintainer, and he wasn't very
helpful (it took him 3 months to respond, and then all he could tell me
was X doesn't use the kernel mouse driver).

Quote:> I offer the following program, which fixes my mouse on Linux at work!

Hey, thanks!  I'll give that a try, but i'd rather find a real solution.

Quote:> Now...if someone could tell me *why* this isn't needed in Windows and OS X,
> I'll be fully happy.

The problem is that IMPS/2 uses a variable number of bytes, rather than
a fixed number.  So, one mouse "command" might be 5 bytes, while the
next is 3.  When the mouse becomes "desynched" it loses the ability to
determine how many bytes it should be reading and then just seems to
give up, reverting back to a fixed byte mechanism (but the mouse
continues to send variable bytes).

Windows and OSX can recognize when the mouse becomes desynched, and
reinitialize the mouse.  XFree86 appears to simply revert back to fixed
byte mode rather than reinitialize.

The worst part about it is, nobody believes that this is a problem.  The
maintainers say that it's a problem with the KVM and refuse to
acknowledge it.

 
 
 

Linux and KVM switches!

Post by William Par » Sun, 23 Feb 2003 01:15:25



> Some people report that if they have an unused port on their KVM, switching
> to Linux, then switching to the unused port, then back to Linux, is more
> reliable.  What I've found on my work system is that if I use ALT-Fn to get
> out of X before switching away, and then when coming back, switch to Linux,
> move the mouse, switch away, switch back, move the mouse again, and then hit
> F7 to go back to X, I'm OK.

> That's quite a hassle!  I did some Googling today, and saw a post on some
> web discussion board from someone who talked about the character sequences
> that are sent to the mouse to configure it.  Based on what he said, I offer
> the following program, which fixes my mouse on Linux at work!

> int main( void )
> {
>    char c[2] = { 255, 255 };
>    int fd = open( "/dev/mouse", 1 );
>    if ( fd >= 0 )
>    {
>        write( fd, c, 2 );
>        close( fd );
>    }
>    return 0;
> }

> If I switch back to Linux, and there is any mouse problem, I run that as
> root, and the problem is fixed.

I move between virtual console and X, and that seems to re-initialize
the mouse.  If I have only console, then I simply kill/restart 'gpm'.

--

Linux solution for data management and processing.

 
 
 

Linux and KVM switches!

Post by Jukka-Pekka Suomine » Sun, 23 Feb 2003 11:41:21




> potato.com says...
>> A lot of people have trouble with wheel mice on Linux when they use
>> a KVM switch.  These are the most common two problems:

> Ahh.. yes, i've talked about this problem in here several times.  Of
> course the usual response I get is denial of the problem, or claiming
> that it's the fault of the KVM.

>> 1. When you switch to Linux, the wheel does not fully work.  E.g., on
>> mine at work, it can scroll down but not up.

>> 2. Moving the mouse causes the cursor to jump wildly, and also makes it
>> act
>> as if buttons are being rapidly pressed.  The result is that you often
>> launch many things from you launch panel thingy.

>> Here is what is odd about this problem.

>> 1. It doesn't seem to be a problem with the mice or KVMs, because they
>> don't have this problem with Windows or Mac.

>> 2. It doesn't seem to happen all the time.  E.g., at home, I have WinXP
>> Pro
>> and Linux on a 2 port Belkin SOHO switch.  I have no problem, other than
>> sometimes the mouse sensitivity changes under Linux.  I never lose the
>> wheel
>> or get the eratic behaviour.  At work, however, with WinXP Pro, Linux
>> (same distribution), and OS X on a 4 port Belkin, I lose half the wheel
>> almost all the time, and get the erratic behavior half the time.

> On my system, the KVM works fine if i'm using PS/2 mode, but flakes out
> if i'm using IMPS/2.  Could it be that your wheel mouse at home doesn't
> use IMPS/2, but emulates it some other way?

> I've done some research on this as well, and it appears to be an XFree86
> problem, not anything specific to Linux itself (though it's in effect a
> Linux problem because Linux uses XFree86).  I've seen the same thing on
> FreeBSD.

> I've spoken with the current mousedev.c maintainer, and he wasn't very
> helpful (it took him 3 months to respond, and then all he could tell me
> was X doesn't use the kernel mouse driver).

>> I offer the following program, which fixes my mouse on Linux at work!

> Hey, thanks!  I'll give that a try, but i'd rather find a real solution.

>> Now...if someone could tell me *why* this isn't needed in Windows and OS
>> X, I'll be fully happy.

> The problem is that IMPS/2 uses a variable number of bytes, rather than
> a fixed number.  So, one mouse "command" might be 5 bytes, while the
> next is 3.  When the mouse becomes "desynched" it loses the ability to
> determine how many bytes it should be reading and then just seems to
> give up, reverting back to a fixed byte mechanism (but the mouse
> continues to send variable bytes).

> Windows and OSX can recognize when the mouse becomes desynched, and
> reinitialize the mouse.  XFree86 appears to simply revert back to fixed
> byte mode rather than reinitialize.

This happens to me "all the time" under win2k, but never with linux. I don't
have a switch, just some crappy Ami optical mouse. It goes berserk under
windows ca. 1 boot-up out of four. I have fixed the problem with unplugging
the mouse, touching the touchpad and then plugging the mouse in again.
(It's a ps/2, dual-scrollwheel mouse, FYI)

--

JP

 
 
 

Linux and KVM switches!

Post by Donn Mille » Sun, 23 Feb 2003 12:06:10



> Windows and OSX can recognize when the mouse becomes desynched, and
> reinitialize the mouse.  XFree86 appears to simply revert back to fixed
> byte mode rather than reinitialize.

So can FreeBSD.  (It looks like you're trying to FUD FreeBSD, in
addition to Linux, now, so I've got to respond.)

Here are the relevant bits from syslogd:

Feb 22 03:59:01 daemonstar kernel: psmintr: out of sync (0000 != 0008).
Feb 22 03:59:01 daemonstar kernel: psmintr: discard a byte (17).
Feb 22 03:59:01 daemonstar kernel: psmintr: out of sync (0000 != 0008).
Feb 22 03:59:01 daemonstar kernel: psmintr: discard a byte (18).
Feb 22 03:59:01 daemonstar kernel: psmintr: out of sync (0000 != 0008).
Feb 22 03:59:01 daemonstar kernel: psmintr: discard a byte (19).
Feb 22 03:59:01 daemonstar kernel: psmintr: out of sync (0000 != 0008).
Feb 22 03:59:01 daemonstar kernel: psmintr: reset the mouse.

I use the console mouse driver -- moused feeding the output to
/dev/sysmouse -- instead of XFree86's on FreeBSD.  Works better than the
XFree86 mouse driver.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

Linux and KVM switches!

Post by Erik Funkenbusc » Sun, 23 Feb 2003 12:44:14




> > Windows and OSX can recognize when the mouse becomes desynched, and
> > reinitialize the mouse.  XFree86 appears to simply revert back to fixed
> > byte mode rather than reinitialize.

> So can FreeBSD.  (It looks like you're trying to FUD FreeBSD, in
> addition to Linux, now, so I've got to respond.)

> Here are the relevant bits from syslogd:

> Feb 22 03:59:01 daemonstar kernel: psmintr: out of sync (0000 != 0008).
> Feb 22 03:59:01 daemonstar kernel: psmintr: discard a byte (17).
> Feb 22 03:59:01 daemonstar kernel: psmintr: out of sync (0000 != 0008).
> Feb 22 03:59:01 daemonstar kernel: psmintr: discard a byte (18).
> Feb 22 03:59:01 daemonstar kernel: psmintr: out of sync (0000 != 0008).
> Feb 22 03:59:01 daemonstar kernel: psmintr: discard a byte (19).
> Feb 22 03:59:01 daemonstar kernel: psmintr: out of sync (0000 != 0008).
> Feb 22 03:59:01 daemonstar kernel: psmintr: reset the mouse.

> I use the console mouse driver -- moused feeding the output to
> /dev/sysmouse -- instead of XFree86's on FreeBSD.  Works better than the
> XFree86 mouse driver.

If this is the same thing as gpm, using raw mode in Linux, then the X
mouse driver is still being used, the console mode driver is just
forwarding raw (uninterpreted) data to X.  The console mode driver
appears to be taking the initiative and resetting the mouse though,
which, in effect, fixes it in X as well.

This is new though, i've seen those out of sync errors many times under
FreeBSD going back many years, but without a reset.

 
 
 

Linux and KVM switches!

Post by Donn Mille » Sun, 23 Feb 2003 13:02:12



> This is new though, i've seen those out of sync errors many times under
> FreeBSD going back many years, but without a reset.

I should point out that this happens when I unplug the external PS/2
mouse from my laptop, and start working the built-in touchpad.  This
causes the mouse driver to kick down from Intellimouse mode to "generic"
PS/2 mode.  Linux 2.4.18 and up doesn't do this.  Maybe 2.6 will, though....

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

Linux and KVM switches!

Post by Erik Funkenbusc » Sun, 23 Feb 2003 13:33:28




> > This is new though, i've seen those out of sync errors many times under
> > FreeBSD going back many years, but without a reset.

> I should point out that this happens when I unplug the external PS/2
> mouse from my laptop, and start working the built-in touchpad.  This
> causes the mouse driver to kick down from Intellimouse mode to "generic"
> PS/2 mode.  Linux 2.4.18 and up doesn't do this.  Maybe 2.6 will, though....

Well, Duh.. unplugging your mouse will cause the a mouse reset.
 
 
 

Linux and KVM switches!

Post by Donn Mille » Sun, 23 Feb 2003 20:13:44





>>>This is new though, i've seen those out of sync errors many times under
>>>FreeBSD going back many years, but without a reset.

>>I should point out that this happens when I unplug the external PS/2
>>mouse from my laptop, and start working the built-in touchpad.  This
>>causes the mouse driver to kick down from Intellimouse mode to "generic"
>>PS/2 mode.  Linux 2.4.18 and up doesn't do this.  Maybe 2.6 will, though....

> Well, Duh.. unplugging your mouse will cause the a mouse reset.

So will a bad mouse cable, IME.  Also, I should note that the external
mouse is probed as an "Intellimouse", and the touchpad is probed as
simply a "Generic PS/2" mouse.  Obviously, the Intellimouse protocol is
using some extra bytes.  I thought this was the main reason for the
mouse losing synch more so than the action of unplugging the mouse.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

 
 
 

1. Linux Hates My KVM Switch..?

Hi-

I have 2 PC's that are connected to a Linksys KVM switch. In the past, I had
Windows 2000 on both machines, and the KVM switch worked just fine.

Now, when installing RH7.1, the mouse is very screwy, won't track, jittery,
seems to be giving out false clicks (windows just open mysteriously, etc). But
when I plug it into the PC directly, the mouse works fine, so I'm pretty sure
XWindows is not mis-configured.

FWIW, the mouse in an M$ Intellimouse (optical).

Dunno what this could be....any ideas?

TIA!

2. How do you return the path of a file?

3. KVM switch's and linux mouse problem

4. Problem installing SLS 1.03

5. Mice, Linux, and KVM switches

6. Help with Mini Linux

7. Linux and KVM Switch

8. installpatch problems under sparc Solaris 2.5.1

9. KVM Switches for Linux and Windows

10. Linux on Fujitsu 420D with KVM switch

11. is OmniCube KVM switch supported in linux?

12. KVM Switch ans Linux (SuSE 9.1)

13. Even more on Linux and KVM switches