[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Mouse configuration during installation needs improvement



> 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.



      


Reply to: