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 system 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: Always 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
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.
*** Bug 55339 has been marked as a duplicate of this bug. ***
*** Bug 77544 has been marked as a duplicate of this bug. ***
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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84196 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.
*** Bug 85268 has been marked as a duplicate of this bug. ***
*** Bug 90595 has been marked as a duplicate of this bug. ***