Bug 89948 (KVM) - Keyboard/Video/Mouse problems occur only when using a KVM switch [NEEDINFO]
Summary: Keyboard/Video/Mouse problems occur only when using a KVM switch
Alias: KVM
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
: 86456 90595 90727 103452 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-30 07:52 UTC by John Williams
Modified: 2015-09-13 14:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-05-01 01:28:48 UTC
hamza.ayed: needinfo?

Attachments (Terms of Use)

Description John Williams 2003-04-30 07:52:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030313 Galeon/1.3.4

Description of problem:
I use a KVM (Keyboard, Video, Mouse) switch to swap between my Linux and 
Windows boxes.  In RH 8.0 this worked fine.  On upgrading to RH 9 when I switch
back to Linux the mouse cursor is not visible.  Killing X with
Ctrl-Alt-Backspace and restarting X restores mouse functionality.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Switch from Linux with KVM switch while running XWindow 
2.  Switch back
3.  Try to use mouse

Actual Results:  Mouse cursor is not visible and clicking produces no effect

Expected Results:  Mouse functionality should be unimpaired

Additional info:

Comment 1 Mike A. Harris 2003-05-01 01:28:48 UTC
While Red Hat certainly hopes that KVM switches work well with Red Hat Linux,
we do not officially support KVM switches.  Many KVM's "just work", while
others may have problems that vary quite widely and are generally not easy
to determine wether the problems are caused by the KVM itself - which is
usually the case, or by the software - which is rarely the case.

Let me try to explain this a bit more at length because users generally
get quite frustrated when told their hardware is unsupported after reporting
a bug like this.  My hope is to explain this in detail, and be able to point
users experiencing KVM related problems here in the future, so everyone
understands why they're unsupported clearly rather than just being told
"sorry, unsupported".

KVM switches are quite varied in how they work, and what they support and
do not support.  Some KVM switches are very good quality, and work with
pretty much all mouse/keyboard/video hardware and with all operating systems
quite well.  Other KVM switches don't quite handle various signals in the
best manner, and might end up working on some operating systems decently
and not on other operating systems.  Some KVMs can just mess with the
signals too much and cause problems.

Here are some specific issues for each device type:

Most KVMs tend to handle the keyboard fairly well, however in some cases the
keyboard can become out of sync and have keys stuck, or the keyboard LEDs for
capslock, numlock, scrolllock might not be properly preserved or not preserved
at all.  Sometimes unplugging or plugging in a keyboard can make the KVM hang,
or can even make XFree86 hang due to keyboard controller going out of sync or
getting stray random signals.  Also, the keyboard repeat rate may not be
preserved when switching between machines either completely, or may randomly
get lost occasionally due to hardware glitches in the KVM.

Some KVM switches are poorly designed, and only work with certain types of
mice and keyboards, and may have problems with wheelmice for example, or with
mice with 5 buttons, or other problems.  Some mice might have 5 buttons and a
wheel, but using them through a particular KVM switch might result in the
mouse appearing to be a 2 button or 3 button mouse with no ability to make
the rest of the buttons work at all.  Some KVMs may have problems only when
switching away, or switching back, perhaps not keeping track of the state
of the device properly, or perhaps by injecting switch bounce into the signal
stream, or by generating reset signals unexpectedly, or even simply just
electromagnetic interference picked up on the generally longer cables used
with KVMs.  Plugging in or unplugging mice might work or might not, and it
might work on some KVMs, and not at all on others.  It might possibly hang a
KVM, or hang XFree86, or other operating system software.

KVM switches, introduce extra cable length which the monitor signals must
travel through, which results in a loss of video quality, and in most cases
lower bandwidth.  Many KVMs documentation clearly state that they only support
resolutions and refresh rates to a certain point for example, which is due
to the degradation of the video signal that occurs as the video passes through
the device and the additional cabling.  Another problem encountered with KVMs
and video, is the "plug and play" signal technically known as "DDC" or Display
Data Channel.  This signal is often blocked by many KVM switches thus preventing
video drivers from properly detecting the capabilities of the monitor attached.
Even when the DDC signal can get through ok, the results returned to the video
driver from the monitor don't accurately reflect the true capabilities of the
combination of the monitor *plus* the KVM, since the KVM lowers the capabilities
of the monitor in most cases.  This is often seen as wavy lines on screen or
other wavy distortions at high resolutions and refresh rates.

The above problems are quite a number of issues that can occur with various
KVM switches out there.  Investigating any particular KVM related problem
generally requires actual physical access to the specific KVM switch itself,
and we don't have such access to all KVM devices out there.  The majority
of KVM related problems that have in fact been investigated at all, generally
turn out to be problems introduced by the KVM hardware itself, and not
problems caused by any software.

Since it is extremely difficult to actually diagnose, and the range of
problems is very large and would require significant manpower to investigate
each reported issue, and result usually in the problems not being fixable at
all, or otherwise not easily fixable, while we do hope KVMs work for people,
we do not officially support them because it isn't feasible to attempt to
do so with the large range of KVM devices out there, and in most cases would
result in us being unable to easily do anything anyway.

Closing WONTFIX as bugzilla doesn't have an UNSUPPORTED resolution.

Comment 2 Mike A. Harris 2003-05-13 08:57:29 UTC
Above, I have tried to provide as reasonable an explanation that I could
as to why KVM switches are officially not supported by Red Hat.  I'll
be using this bug report as a master to duplicate future KVM related bug
reports against since I've put a rather detailed explanation above.  In order
to enhance the above explanation, I've searched through our bugzilla and have
gathered together a list of specific examples of problems reported to us in
the past to further illustrate what I'm saying above.  This will help users
to not have to rummage through bugzilla themselves, should they wish to see
specific cases of some of the issues I mention above.  The previous master
duplicate, which contains a similar but not as complete explanation of KVM
related problems is:

    Bug #76124

A few other KVM related bug reports include: Bug #55339, bug #77544

Comment 3 Mike A. Harris 2003-05-13 09:04:42 UTC
*** Bug 90595 has been marked as a duplicate of this bug. ***

Comment 4 Mike A. Harris 2003-05-20 22:36:55 UTC
*** Bug 86456 has been marked as a duplicate of this bug. ***

Comment 5 Michael J. Kofler 2003-05-21 20:18:27 UTC
Having read the explanation above, I'm still confused about one thing: The KVM
that I'm using (the box says Data Sharing Service [the company name?]; Manual
Data Switch Box) has worked with every RH distro since 6.2. The problem started
after upgrade to RH9. Logically, it would seem that the problem is somehow
software related, as everything else with the system has remained constant (same
mouse, keyboard, monitor, etc). 
As a test, I tried physically unplugging the PS/2 mouse then pluggin it back in,
independent of the KVM (this was tried both with the KVM plug and then with the
actual mouse plugged directly into the linux box, completely independent of the
KVM). The result was the same: the mouse did not work after pluggin it back in.
On previous RH versions, and on my windoze box, the mouse works again once it's
plugged back in.
So it appears that the problem is not with the KVM switch, since the same
behavior is found without the switch, but rather with the way RH9 handles the
mouse. Running redhat-mouse-config returns functionality to the mouse, as does a
less elegant ctrl-alt-backspace X restart. 
On the bright side, having to reconfigure the mouse everytime makes me less
likely to switch over to my windoze box!  :)

Comment 6 Mike A. Harris 2003-05-22 12:55:21 UTC
KVM's are nonetheless unsupported.  Even if it is something that has changed
by XFree86.org in the software, it is not something we can investigate or try
to fix because we do not have one of every possible KVM switch, mouse, keyboard,
monitor and other piece of hardware out there.  This is why this stuff is
specifically unsupported.  Because there are tonnes of problems with KVMs,
and it is exceptionally difficult to determine whether they are caused by
hardware, or software, or can be fixed via software.

If the KVM worked in an older release, and does not in RHL 9, my recommendation
is twofold:

1) Downgrade the OS to a version with which it just luckily happened to work
   even though it was working but still unsupported.

2) File a bug report at http://bugs.xfree86.org so that the XFree86 developer
   community is aware of this change.  While Red Hat does not support KVMs
   with XFree86, it is possible that the community may be willing to investigate
   the problem, and try to create a hack workaround in the X server.

ABL Masterview KVM switches work fine for me in all releases of the OS so far.
That isn't an endorsement however, just a datapoint.  My KVM switch is also
unsupported, and if a future release causes it to not work, then I will be
out of luck too (unless I try to debug it on my own personal time).

If upstream comes up with some hack workaround, I'm more than glad to
spend a bit of time reviewing it and determining wether or not it is something
we can consider safe to include in a future release or not.

Keep in mind, that even if something is totally unsupported by Red Hat, it
might actually work flawlessly.  And it might not work in the future also.

Yours is a case of that it seems.

Comment 7 Mike A. Harris 2003-05-22 20:10:03 UTC
*** Bug 90727 has been marked as a duplicate of this bug. ***

Comment 8 Mike A. Harris 2003-08-31 14:34:36 UTC
*** Bug 103452 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.