Re: MOUSE won't function
On Fri, Jan 17, 2003 at 08:43:04AM -0800, Joris
Huizer wrote:
I just want to get debian working as soon as possible and it seems the *only* problem right now is the lame mouse...
I had a look at the page. However, it says I have to run:
gpm -m /dev/input/mice -t imps2
(which doesn't do anything as gpm is allready running) - and it says I can make this default by editing the "initialisation file named sumething like rc.d" -
however it doesn't tell were that is in Debian - can you tell me where I should edit ?
--- Pigeon <jah.pigeon@ukonline.co.uk> wrote:
gpm may be your problem then. You have to use the -R option to make it repeat the mouse data on /dev/gpmdata, then edit your XF86Config to read from /dev/gpmdata instead of /dev/psaux or /dev/input/mice.
Joris Huizer wrote:
I never heard about /dev/gpmdata before - and it doesn't seem to exist; Should I make a symlink or folder there or something?
--- Pigeon <jah.pigeon@ukonline.co.uk> wrote:
Alternatively, if you're not interested in using the mouse in text consoles, try killing gpm altogether.
Joris Huizer wrote:
? what do you mean isn't gpm the hole X or what ?
Sounds like you may be confusing gpm with gdm with X with the mouse
driver in X.
Basics:
You can have the graphical windowing system, the X Window System,
running, or not. If you have it running, it can be started manually from
a text-only terminal with a command like "startx", or it can be started
automatically via the system startup scripts using an X Session Manager.
The four most popular session managers are xdm (the old "original"), wdm
(a "fancier" one), kdm (KDE's session manager), and gdm (Gnome's session
manager). Note that you can use gdm even if you're not running the Gnome
desktop environment, and you can run kdm even if you're not running KDE.
So, don't confuse the mouse driver program for the console, gpm, with
the graphical logon session manager, gdm.
So, no, "gpm is not the [w]hole X or what". gpm has nothing to do with X.
gpm is a mouse driver for the text-only virtual console. For example, if
you are not running X, and you only have text-only virtual consoles
(hereafter referred to as VTs, for Virtual Terminals), and you need a
mouse in your VTs, then you'd need to be running gpm. Or even if you are
running X, but you occasionally need to pop out to a VT and need a mouse
while there, you'd need gpm running.
Now, if you have X running, X needs a mouse. It has its own mouse driver
built-in. This mouse driver conflicts with gpm, and having gpm running
as well as X can cause the mouse to behave erratically, etc, because the
mouse might generate some events, such as "I've moved left", followed by
"I've moved up". If both gpm and the X mouse driver are reading the
mouse port, it may be that gpm reads the "left" event, removing that
event from the incoming data stream, and then it comes X's turn to read
the mouse events, and it reads "up", never getting a chance to read the
"left" event because gpm "took" it. So the mouse behaviour in X was
supposed to be left, then up, but turns out to be only up. Doh!
Thankfully, these two mouse drivers can be convinced to play nicely
together. The way this is done is to tell gpm to not keep the incoming
data to itself, but to repeat that incoming data, in a "raw" format.
Both gpm and X normally read from the "incoming mouse data port"
(whatever that is, perhaps /dev/psaux, perhaps /dev/ttyS0, etc). gpm
can't repeat the data it reads back to that port, or next time it goes
to read that port it'll just re-read what it read earlier, and
loopity-loop. So instead it repeats the data to a special "virtual"
port, called /dev/gpmdata. Then X needs to be configured to read its
incoming mouse data, not from the normal port, but from the /dev/gpmdata
"port". Voila! gpm and X now get along just dandy.
So, you have two options.
1) Remove gpm, and just get the mouse working in X
2) Configure gpm to repeat the raw data (run gpmconfig and answer the
questions), and configure X to read its mouse data from /dev/gpmdata.
I personally would go for number 2, because then you can troubleshoot
mouse behaviour in a "simpler" VT, without all the other baggage of
getting X to work. It also gives you more functionality (mouse in VTs).
However, if you're working on a system with tight memory, I'd forego gpm
in favor of number 1.
You can remove gpm with a command like "apt-get --purge remove gpm".
Or you can leave it installed, and manually stop, start, restart it with
a command like "/etc/init.d/gpm stop" or "/etc/init.d/gpm restart". You
can see if it's currently running with a command like "ps ax | grep
[g]pm". If any lines show up containing gpm, yep, it's running. (Without
the brackets around the 'g', the ps command itself with be shown as a
running process.)
You mention that you "just had a look at the page", but don't mention
what page this is, so I have no clue what that refers to. But the "rc.d"
you reference may be a RedHat-ism. There are directories in /etc named
such things as rc0.d and rc3.d, and I _think_ these directories may be
under a "master directory" named "rc.d" on Redhat, but I'm not sure. At
any rate, these rc directories are where you'll find startup scripts for
the various runlevels. Actually, these are just symlinks to the actual
scripts, which are in /etc/init.d. Debian has a program called
"update-rc.d" which can help to manage these symlinks to the startup
scripts (so that you can remove a program from a runlevel without
actually removing the program from the system, etc).
You shouldn't have to create /dev/gpmdata. It should either be there, or
perhaps gpmconfig creates it when you configure gpm to use it. I'm not
sure on this.
Hope this helps.
Kent
Reply to: