Bug 76124 - Mouse locks when using Omnicube
Summary: Mouse locks when using Omnicube
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
: 55339 77544 85268 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-17 07:57 UTC by Martin Hickling
Modified: 2007-04-18 16:47 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-10-17 07:58:04 UTC

Attachments (Terms of Use)

Description Martin Hickling 2002-10-17 07:57:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)

Description of problem:
Inital request

I have been running RedHat since Novenber last year from 7.1 to 7.2 and 7.3. I 
use a swith box (Belkin Omnicube) to control 4 towers. I have just installed 
RedHat 8.0. Now every time I switch away from the RedHat 8 box and back I loose 
control over the mouse. The only way to get it back is to CTRL-ALT-DEL and 
relogon. As this behaviour is new to RedHat 8 and has not shwon in the previous 
12 months are there any settings or drivers that can be changed to correct this 

First Reply

I regret to inform you that configuration of RedHat Linux which is running 
though a switch box is beyond the scope of Basic Installation Support. You may 
view our Service Level Agreement on this link: 
http://www.redhat.com/support/sla However, I can try to help you configure your 
mouse so that you don't have to reboot your PC. This is how you can configure 
your mouse to work in the Xwindows environment. First step to do if your are in 
the Xwindows environment, is to exit it. This is because configuring the mouse 
requires that you do not have any desktops open. Although it might work without 
shutting down Xwindows, it is more advisable to do so. Shut the desktop down 
with these steps: 1. Press Ctrl-Atl-F2 to get into a text environemnt. 2. Login 
and run this command to shut down the Xwindows that was running: init 3 3. Now 
configure your mouse with this command: mouseconfig 4. To start the Xwindows 
session. Run this command: startx I hope this helps. If you have other 
installation concerns, please feel free to create a new ticket. 

My Response

I followed your instructions and changed the mouse. When I rebooted the mouse 
was not recognised at all. I followed the instructions again but set everything 
back to the original mouse. It all seems to work fine now and I have no problem 
switching between boxes but it is a bit strange!
Final Reply

I'm glad that you got the mouse working now. This could actually be a bug. 
Although this kind of configuration is not supported by Basic Installation 
Support, the general RedHat community may find this information useful. What 
you can do is to file a bug report to our RedHat Developers. To file a bug 
report, please go to this webpage: http://bugzilla.redhat.com If you have other 
installation concerns, please feel free to create a new ticket.

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

How reproducible:

Steps to Reproduce:
1.Logon on
2.switch to different box via Omnicube
3.switch back

Actual Results:  mouse jumps to bottom left of screen and does not move very far

Expected Results:  mouse should contioue working normally

Additional info:

the only recourse is to CTRL-ALT-DEL and re log-on

Comment 1 Mike A. Harris 2002-10-17 08:26:32 UTC
Red Hat does not support KVM switch related bugs/problems.  The reason
for this, is that almost all KVM switches modify the signal between the
computer and the mouse/keyboard.  Many switches do so in a totally dumb
way, and others just have random hardware conflicts with certain specific
mice/keyboards.  Also, some KVM's simply do not support every single
mouse protocol out there, or the features of some mice.  In all of these
cases, and other cases, the fault of the problem is the KVM itself, and
not the operating system.

So, since there is nothing we can do about these problems really, they
are unsupported.

That said, some KVM related problems are due to the KVM making the mouse
appear to be a different mouse, by changing the protocol.  For example,
you might use a mouse normally with the IMPS/2 protocol.  Then you add
in a KVM, and now your mouse wont work.  The KVM might have changed
the mouse to use the PS/2 protocol instead.  Or perhaps vice versa.
This is a hardware issue with the KVM.

In addition, any problems that are hack-aroundable via software "potentially",
generally can't be done simply because of:

1) lack of hardware (a developer working on it, doesn't have the
   specific KVM switch which a given problem could potentially have a
   software workaround.  Also, in depth technical documentation would
   be required for the KVM, and the various mice that might be
   problematic.  In short - nobody has the hardware the problems are
   happening on that could potentially fix it, if there was a way to
   fix it (and most problems there isn't.)

2) The number of people experiencing a given problem with KVM's and
   reporting it are extremely small.  Resource allocation to look int
   a given problem a user is experiencing is dependant on both having
   access to the given hardware and its documentation (#1 above),
   and it being a widespread enough problem to justify prioritization
   of allocation of engineering resources to investigate the problem
   and/or fix it.

So, in summary, we do not support KVM's, as we _cant_ support them.

If it worked before for you, try using the same configuration files
you used before when it worked for you.  My guess is the mouse configuration
you used before, is not the same as it was now.  If that doesn't work,
then all I can suggest is to not use the KVM switch.

Sorry I'm unable to help further.

Comment 2 Mike A. Harris 2002-11-09 00:46:52 UTC
*** Bug 55339 has been marked as a duplicate of this bug. ***

Comment 4 Mike A. Harris 2003-05-13 08:32:16 UTC
*** Bug 77544 has been marked as a duplicate of this bug. ***

Comment 5 Mike A. Harris 2003-05-13 08:41:25 UTC
I'm trying to link KVM related bug reports all to this one bug report, so that
it can be used as a reference in the future.

Adding link here for completeness sake, to one reported KVM problem which
happened to be able to be worked around in XFree86 via a hack:


It is possible in theory that some other KVM related problems may be able
to be worked around via similar hacks, or may be fixed by this hack also.
If KVM users experiencing problems are able to create a hack to XFree86
which works around their problem also, and does not regress the software
at all, they should submit their bug report to XFree86.org via the
XFree86 bugzilla located at http://bugs.xfree86.org and if it gets accepted
into the official source code tree, it may end up in future releases of
Red Hat Linux.

Even though KVM switches still remain officially unsupported, and we do not
provide engineering support for such workarounds, if someone can
produce a workaround that doesn't harm anything, a solution may be
possible for some of these problematic switches.
for some problems.

Comment 6 Mike A. Harris 2003-05-13 08:43:39 UTC
*** Bug 85268 has been marked as a duplicate of this bug. ***

Comment 7 Mike A. Harris 2003-05-13 09:03:19 UTC
*** Bug 90595 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.