Hide Forgot
Using XFree86-3.3.3 with the 3DLabs X-server, or using the Accelerated-X server from X-Inside Graphics, the PS/2 Intellimouse works correctly ONLY with the generic RH 5.2 kernel. When I rebuild the kernel (so I can get a ppp-connection to my ISP; see Bugzilla Bug 727), then any movement of the mouse causes the cursor to jump to the top of the screen and stay there, moving erratically as the mouse is moved. All kernel rebuilds that I've tried have this problem, even when I use all of the defaults in xconfig (except ISDN and SCSI support removed). Interestingly, the Metrolink X-server works fine with all of the kernel versions I've tried. Note that in all of the kernel rebuilds, I've paid special attention to the mouse-support/drivers, trying various permutations, but to no avail.
A related question: If I rebuild the kernel and modules using the defaults for "make xconfig", i.e. the default configuration settings, should the new kernel and modules be the same as those from the generic RH kernel? Or at least nearly the same? If not, could I get a copy of the RH .config file and try building the kernel from that to see if the problem persists? At this point I see no reason why my "custom" kernel should be significantly different from the generic RH kernel, especially with respect to the operation of the X-server, and in particular the PS/2 mouse.
It sounds like your config files for X have become set incorrectly. You can run mouseconfig and the re-run Xconfigurator. This should detect your mouse and reset XF86Config to the proper values for your mouse. If this does not solve the issue, then you can reopen the bug. MetroX use a completely different config file so that could explain why it works and XFree does not.
The problem cannot be with the configuration files because if I reboot using the RH generic kernel, without changing the X configuration (either for XFree86 or Accelerated-X), then the X-server/mouse works correctly (with either). At this point I'm fairly sure that it is somehow related to the kernel/modules since nothing else is being changed when I reboot to one or the other kernel version. I probably would not have contacted you with this "anomaly" except for the fact that it is showing up with two substantially different X-servers (XFree86 and Accelerated-X), and I think I've checked out most of the more obvious possible causes. What is bothering me is that I cannot build a custom kernel, even with the "default" configuration, and then get the X-server to work correctly with that kernel. It is certainly not in your interest to help me solve problems related to my "custom" kernel builds, but on the other hand I'm reasonably convinced that there may be more to this than just my blundering. Either way, is it possible for me to get a copy of the .config file used to compile the RH generic kernel, or is the default-generated .config file the same as that?
I found the problem, or at least a fix. The problem appears to be with the mouse driver [linux/drivers/char/psaux.c] where the constant INITIALIZE_DEVICE needed to be set. As distributed by RH, it is NOT set in the source file; the line is commented out. This brings up an interesting question: Is the mouse initialized with the generic RH kernel (the xconfig default compiles the driver into the kernel)? If so, then perhaps the distributed source code should have the line uncommmented?
This is being assigned to a developer for further review.
Further information for you, possibly confirming the mouse initialization issue. If I boot up using the generic RH kernel and run the Accelerated-X (or XF86_3DLabs) server, it works fine. However, anytime after I've run the Metro-X server the other two servers fail to work correctly with the mouse. Recall that the Metro-X server works correctly with or without mouse initialization. Apparently, it would be necessary to somehow reinitialize the mouse after using Metro-X in order for the other two servers to work correctly. Most importantly, this is true for even the generic RH kernel, not just the rebuilt ones.
I am unable to reproduce this problem. The configuration RH used for the generic kernel is availavle in arch/i386/defconfig in the kernel source tree. Metro X is not a supported product for 5.2 - you will need to contact Metro to get support on that issue.