Re: Mouse configuration during installation needs improvement
Stephen Powell <[EMAIL PROTECTED]> writes: > Thinkpad 600). But I'm impressed. Theoretically, one > is not supposed to be able to hot swap a PS/2 mouse. > But it works. Kudos to the kernel folks. The problem has never been that the mouse didn't work after a hot swap. The problem is that with PS/2 the power surge on the port, as little as it is, may well fry your mainboard. Obviously in the last 10 or so years mainboards have become a bit more resilient to this because people to tend to accidentally pull a mouse cable every now and then and plug it back in. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
Well shut my mouth! I did some testing this past weekend, as I said I would, and results are better than expected. First, leaving things the way I had them configured (X pointing to /dev/gpmdata and gpm pointing to /dev/psaux, I unplugged the PS/2 mouse from the mouse port. The mouse became dead in both X and gpm (duh!). I then plugged it back in again. It worked again, both in X and in gpm! Then I configured X and gpm both to use /dev/input/mice and turned off gpm's repeater function. After restarting both daemons and verifying that both X and gpm could use the mouse, I again unplugged the mouse. Again it was dead in both X and gpm (duh!). And again I plugged it back in and it started working again, both in X and in gpm, with no action on my part. I didn't have to restart the gpm daemon, I didn't have to restart X, I didn't have to unload and reload a kernel module, etc. This is better than I expected. Of course, this is on a different machine (a Dell Dimension 4400) than I last tried this on (an IBM Thinkpad 600). But I'm impressed. Theoretically, one is not supposed to be able to hot swap a PS/2 mouse. But it works. Kudos to the kernel folks. The repeater function of gpm now appears to be obsolete, as you say. I would still like to see gpm installed by the Debian installer whenever a mouse is detected on the system in order to allow copy and paste in a virtual console. But I'm not going to flog a dead horse. The powers that be obviously don't like that idea. Thanks to all contributors to this thread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
Since my initial post I have done some research on the subject of mouse support in the Linux kernel. I can see now why my suggestion was met with such strong opposition: it goes counter to the direction the kernel has been going since 2.5. With such a sweeping redesign of mouse support since 2.4, I think I need to do some experimentation to see if gpm still provides one of the key benefits that it once provided, namely the ability to resurrect a dead PS/2 mouse after unplugging and replugging. On older kernels, I could issue the following command which nearly always regained the use of the mouse in a virtual console: /etc/init.d/gpm restart And if X was set up to use /dev/gpmdata, this would of course also resurrect the mouse in X too. Thomas Hood, in his web page for Debian GNU Linux on an IBM Thinkpad 600, specifically recommends this (http://panopticon.csustan.edu/thood/tp600lnx.htm). However, this information appears to have been written when he was running a 2.4 kernel. On my system, gpm is currently configured to use the legacy mouse port /dev/psaux, but it appears from what I've read that this "device" no longer gives the direct access to the physical port that it once did. I wouldn't be surprised if gpm has thereby lost its ability to resurrect the mouse. I'll do some testing over the weekend and let you know what I find out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
[Stephen Powell] > I realize that PS/2 mice were not intended to be hot swapped, but > "stuff happens". The kernel 'psmouse' module, and the 'serio' layer that actually talks to the i8042, actually have much more thorough and robust support for PS/2 hotplugging than gpm ever did. The kernel even intelligently handles PS/2 multiplexing, as seen on many laptops where the trackpad shares the chip with an external port. (gpm treats that case as a single mouse, programmed for some protocol they have in common.) As gpm co-maintainer I will say that the gpm repeater seems to be entirely obsolete for all use cases. (Unless your kernel is pre-2.6, but Debian no longer supports that.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Re: Mouse configuration during installation needs improvement
On Thu, May 29, 2008 at 12:22:15PM -0500, Ron Johnson wrote: > Which I did many years ago. But it would still make it easier for > us dual-use people, and not affect only-gooey users, if gpm were the > default. I would like ssh installed by default before gpm, but I don't think we need to go back to doing that either. The admin installing the machine should decide what to add to the base system. For that matter, gpm is only useful on machines with a mouse, some machines just have serial consoles. They have great use of login and getty, and such, but gpm and X just waste space. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Mouse configuration during installation needs improvement
On Thu, May 29, 2008 at 07:35:20AM -0700, Stephen Powell wrote: > 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. It was a very nice improvement. > 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. For a PS/2 port, there is NOTHING software can do to recover. The hardware on the majority of PCs requires a reset for the PS/2 port to come back to life. gpm is of no help here. X does mouse handling just as well as gpm does. > 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. /dev/input/mice actually has the kernel convert all known mouse formats to one protocol as far as I know, so all those mouse protocol issues are gone too. > 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. gpm is NOT a driver. It is a tool that can use the mouse interface in the kernel and do useful things with the terminal. Other programs could do the same if they wanted to. it is not a driver though. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
On Thu, May 29, 2008 at 08:16:28AM +1000, Ben Finney wrote: > Where is your data for this assertion? The number of people that have no idea how to get to the console from X. Personally I hate dealing with machines that don't have gpm installed, but I don't want to bloat the base install either. > This argument would also see the removal of 'login', since that's not > needed by your putative majority of people who don't log in over > text-only interfaces. The default system does not have X. Not having login prevents you from working. Not having gpm is at worst slightly inconvinient. > This argument fails for the same reason: just because *few* people use > it is not sufficient reason to drop it from the install. If you don't > want 'gpm' installed, you need a different argument. Don't install stuff that is non essential. gpm certainly is not essential, so don't install it. login is essential, so do install it. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/08 11:25, Frans Pop wrote: > Ron Johnson wrote: >> On 05/29/08 09:35, Stephen Powell wrote: >>> 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 > > I work mainly in consoles too but I have no use at all for gpm as my > consoles are normally all in a graphical environment (KDE's konsole, either > local or ssh sessions). ? The console is The Console, the keyboard and monitor directly (or via a KVM switch) connected to the computer. >> Amen. This is Debian, not Ubuntu. > > Correct. Which means we have cluefull users who know how to run 'apt-get > install gpm' if they are heavy VT users. :-D Which I did many years ago. But it would still make it easier for us dual-use people, and not affect only-gooey users, if gpm were the default. - -- Ron Johnson, Jr. Jefferson LA USA "I must acknowledge, once and for all, that the purpose of diplomacy is to prolong a crisis.", Mr. Spock -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIPuZHS9HxQb37XmcRAq3vAJ0YHX9Y/5issNu/EJn0e0l93iLOWgCg4x3l os1HhbzIndBGN3JCXHaVn9I= =kiRw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
Ron Johnson wrote: > On 05/29/08 09:35, Stephen Powell wrote: >> 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 I work mainly in consoles too but I have no use at all for gpm as my consoles are normally all in a graphical environment (KDE's konsole, either local or ssh sessions). > Amen. This is Debian, not Ubuntu. Correct. Which means we have cluefull users who know how to run 'apt-get install gpm' if they are heavy VT users. :-D Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Re: Mouse configuration during installation needs improvement
On Thu, May 29, 2008 at 07:35:20 -0700, Stephen Powell wrote: > 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. > If X listens to /dev/input/mice, it doesn't care that you unplugged your mouse and plugged it again, so I'm not sure what you think gpm provides here. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/08 09:35, Stephen Powell wrote: [snip] > >> 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 Amen. This is Debian, not Ubuntu. - -- Ron Johnson, Jr. Jefferson LA USA "I must acknowledge, once and for all, that the purpose of diplomacy is to prolong a crisis.", Mr. Spock -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIPslcS9HxQb37XmcRAsuYAKCeyvicHUjRnFrLMUjAptBEWAGVFQCbB08Y SXKM/1VgwXSniUZUGXddY0U= =WUBA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
Quoting Ben Finney ([EMAIL PROTECTED]): > [EMAIL PROTECTED] (Lennart Sorensen) writes: > > > Given most people don't use the console ever > > Where is your data for this assertion? Probably too wide generalization by Lennart. My own assertion was that people who use the console *on an enough regular basis* (ie to do real work) are clever enough to figure out that using the mouse in the console needs installing gpm. I think that this assertion is true. Of course, I have nothing to prove it except common sense (I was about to joke and say that the people mentioned above are Joey Schulze:-)) > > installing a service that is only for console use by default is > > simply wrong. The less services need to be enabled by default the > > better. > > This argument would also see the removal of 'login', since that's not > needed by your putative majority of people who don't log in over > text-only interfaces. ...which would mean dropping the possibility of having a basic login in virtual consoles. Of course, noone will ever think that. The point I bringed in that discussion is that virtual consoles are essentially a fallback for the vast majority of users. And one could assume that a mouse is not strictly needed for a fallback. > > This argument fails for the same reason: just because *few* people use > it is not sufficient reason to drop it from the install. If you don't > want 'gpm' installed, you need a different argument. What we want to bring is that having only few people needing it makes a good reason to not install it by default (and have it ask questions to users, indeed). signature.asc Description: Digital signature
Re: Mouse configuration during installation needs improvement
On jeu, 2008-05-29 at 08:16 +1000, Ben Finney wrote: > This argument would also see the removal of 'login', since that's not > needed by your putative majority of people who don't log in over > text-only interfaces. Do you _really_ think gpm is as important as login? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Mouse configuration during installation needs improvement
[EMAIL PROTECTED] (Lennart Sorensen) writes: > Given most people don't use the console ever Where is your data for this assertion? > installing a service that is only for console use by default is > simply wrong. The less services need to be enabled by default the > better. This argument would also see the removal of 'login', since that's not needed by your putative majority of people who don't log in over text-only interfaces. This argument fails for the same reason: just because *few* people use it is not sufficient reason to drop it from the install. If you don't want 'gpm' installed, you need a different argument. -- \ "The shortest distance between two points is under | `\ construction." -- Noelie Alito | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
On Wed, May 28, 2008 at 06:49:17AM +0200, Christian Perrier wrote: > Not to mention the various remarks that have been made, I would like > to enhance that ppl who use the Linux console on a regular basis > (which is usually what motivates activating a mouse on it) are > perfectly able to know that gpm is the package to install if one wants > support for the mouse in the console. > > So, do we really want to install/configure GPM for any user of the > system, knowing that a very large part of users will never use > itand those who might need it are perfectly able to figure out how > to do "aptitude install gpm"?? > > In short, I don't think that having gpm by default is worth it. Given most people don't use the console ever, installing a service that is only for console use by default is simply wrong. The less services need to be enabled by default the better. And installing gpm later if needed still allows it to get along with X so there is no problem, contrary to the original post. There was in the past, but the kernel has improved since then. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mouse configuration during installation needs improvement
Quoting Stephen Powell ([EMAIL PROTECTED]): > This will allow the use of the mouse both in a virtual > console and in X. Not only that, but "hot swapping" Not to mention the various remarks that have been made, I would like to enhance that ppl who use the Linux console on a regular basis (which is usually what motivates activating a mouse on it) are perfectly able to know that gpm is the package to install if one wants support for the mouse in the console. So, do we really want to install/configure GPM for any user of the system, knowing that a very large part of users will never use itand those who might need it are perfectly able to figure out how to do "aptitude install gpm" ? In short, I don't think that having gpm by default is worth it. signature.asc Description: Digital signature
Re: Mouse configuration during installation needs improvement
Lennart Sorensen wrote: > 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. Of course PS/2 mice can not be connected while > the system is on, since the hardware simply is not designed for that (I > believe it can actually be damaged by trying although I have no seen it > happen.). On a few systems it seems to work if you plug in a ps/2 mouse > on the fly, but on the vast majority it does not work until you reset > the system. USB mice of course are hot plug and hence much simpler. > > I like gpm, and use it, but I no longer point X at it like I used to > now that the kernel allows mouse sharing at all times (as long as you > don't try to use the obsolete /dev/psaux device to access the mouse). > > gpm would also be on the first CD already, if lots of people used it. > Apparently they do not. gpm also leads to a number of complications for some users, as seen in the BTS. -- see shy jo signature.asc Description: Digital signature
Re: Mouse configuration during installation needs improvement
On Tue, May 27, 2008 at 12:57:11PM -0700, Stephen Powell wrote: > Per the suggestion of J?r?my Bobbio when he closed Bug > # 481514 against installation-reports, I am posting > this item to the debian-devel mailing list. > > The Debian installer needs some improvement when it > comes to mouse configuration. Currently, if the user > requests a "standard system" and a "desktop > environment" in the Debian installer, the X Window > System will be installed in such a way that it drives > the mouse directly, rather than going through gpm; and > gpm is not installed. I recommend that gpm be > installed whenever a mouse is detected on the system; > and if the X server is also installed, it should > always be configured to get mouse events from the gpm > daemon rather than drive the mouse directly. > > This will allow the use of the mouse both in a virtual > console and in X. Not only that, but "hot swapping" > the mouse will be far less disruptive for X users. > When the X server drives a standard PS/2 mouse > directly, if the user unplugs the mouse and plugs in > another one while the system is running, he must stop > and restart the X server, losing all of his X > applications in the process, in order to regain the > use of the mouse. But when using gpm, all he must do > is stop and re-start the gpm daemon to make the mouse > work again. The X server is unaffected and the X > applications are unaffected. > > With this recommendation, you should also move gpm to > CD-ROM number 1. 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. Of course PS/2 mice can not be connected while the system is on, since the hardware simply is not designed for that (I believe it can actually be damaged by trying although I have no seen it happen.). On a few systems it seems to work if you plug in a ps/2 mouse on the fly, but on the vast majority it does not work until you reset the system. USB mice of course are hot plug and hence much simpler. I like gpm, and use it, but I no longer point X at it like I used to now that the kernel allows mouse sharing at all times (as long as you don't try to use the obsolete /dev/psaux device to access the mouse). gpm would also be on the first CD already, if lots of people used it. Apparently they do not. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
