> With current kernels, if you use /dev/input/mice, the > port can be shared > by gpm and X at the same time, and all mice you connect > (no matter what) > show up in that device.
Thanks for the update on mouse sharing in newer kernels. I didn't realize that this support had been added. That does take away part of my supporting argument for configuring X to use gpm. > Of course PS/2 mice can not be connected while > the system is on, since the hardware simply is not > designed for that ... I realize that PS/2 mice were not intended to be hot swapped, but "stuff happens". Sometimes the connector is loose and falls out, sometimes a mischievous co-worker unplugs it as a practical joke, sometimes the mouse fails, sometimes someone trips over the cord, sometimes the dog chews on it, sometimes an inquisitive toddler unplugs it, etc. Being able to recover from these things without requiring a reboot (or at least restarting the X server) is a nice feature, one that gpm provides. > gpm also leads to a number of complications for some > users, as seen in the BTS. Well, as Scotty of Star Trek fame says, "The more they overtink the plumbing, the easier it is to stop up the drain." (Star Trek III: The Search for Spock) But then again, you could make that argument for the new kernel support for mouse sharing too. Yes, adding another layer of software also adds another thing that can go wrong. The key is to make the benefits greater than the cost. I can only say that I have used gpm on several different machines under several different releases of Linux, and I have never had a bit of trouble with it. In some cases I seem to remember it allowing the mouse to work when X couldn't drive it directly (the "fups2" protocol came to the rescue). And it has saved my hindquarters when the mouse got unplugged somehow. > Given most people don't use the console ever, > installing a service that > is only for console use by default is simply wrong. I'm not sure how one would know that most people don't use the console. I, for one, use it a lot. But even it it's true, I don't see why a device driver for a device that is present on the system shouldn't be installed. Should you not install serial port support because most people don't use the serial port? It won't HARM people who DON'T use the console, will it? We're talking about basic hardware support here, something that many applications can use -- not an application. Please reconsider. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]