Re: Diagnosing mouse in text mode (was Re: Gnome file window keeps popping up)


Allan Adler wrote:
Allan Adler <ara@xxxxxxxxxxxxxxxxxxxx> writes:

Hi;
Firstly - to address an earlier Gnome logout issue;
You should always be able to use (some form of) the keyboard's TAB,
SPACEBAR, Alt, Shift, ENTER , Up/Down Arrows keys to jump around to any
GUI widgets (highlight to select, then ENTER, or SPACEBAR (usually to
place/remove a tick mark in a checkbox)).

I got the answers I needed on comp.sys.ibm.pc.hardware.misc. The solution
was to use a DOS boot disk containing a mouse driver, a copy of qbasic and
a mouse demo program written in qbasic to test the mouse. It determined
that the mouse was not working; in fact, error messages from the mouse
driver already showed that. I replaced the mouse with another PS/2 mouse
from another computer and the demo showed that this one was working (the other
computer was running no programs that could test the mouse before I acquired
the DOS boot disk, etc.). Then I booted Linux with this replacement mouse
and tried it out again in Gnome, where it didn't work. I ran
/usr/sbin/mouseconfig --expert
and after some experimentation with the mouse type and starting x, I finally
got it to work by telling mouseconfig that it was a
Logitech MouseMan/FirstMouse (PS/2). So, now I'm operational again.

What I'd like to know is how I could have made the same easy diagnostics
of the mouse using what was available to me under RH 7.1 Linux, which is
what is running on the HP Pavilion.

The easiest fastest way to diagnose ANY (possible) hardware issue is to
replace the device with a known good one, This should be (many times)
the first thing one does when having trouble with a device. I preach
better than I listen to my own words sometimes though ;-)
I recently struggled with a broken keyboard -- but refused to admit the
issue was a hardware one, and racked my brains for a few days till I
got fed up enough to try a replacement.

Of course, starting Gnome and realizing
that the mouse doesn't work is a kind of diagnostic, but that diagnostic failed
to distinguish between the defective mouse and the replacement that worked
until I'd experimented enough with mouseconfig. By way of contrast, there was
no difficulty or subtlety in testing them under DOS (or rather FreeDOS).

Let me put my question a little differently and a little more concisely:
suppose I am using Linux in text mode and I want to diagnose the mouse
without leaving text mode. How do I do it?

These articles may help (specifically 'gpm' related stuff)...

Have a look around and perform searches - since the archive goes backl
in time quite a ways, and may yield info _specific_ to your older RH
7.1 distribution.

For ex; This was written ~ 1997
=============
http://www.linuxjournal.com/article/2558

My Mouse Won't Work

Q.
My new system came with a new Microsoft Mouse. This mouse doesn't work
with Linux. After a couple of days of messing around, I've come to the
conclusion that there is a problem with my model of the Microsoft
Mouse--on the underside of the mouse is the designation Serial Mouse
2.1A. I have concluded that the problem lies with this mouse because
the new system works perfectly well with my old Microsoft Mouse. Is
something wrong with the new mouse?

A.
I don't have access to the newest mouse, so Francois Chastrette has
helped a lot with this problem. We are working on a satisfactory
solution to include in gpm 1.12 right now (end of August). By the time
you read this Linux Journal, the new version of the mouse server should
be available by FTP.
X support might take a bit longer as the X team has a huge package to
manage. In the meantime, you can use the -R option of gpm to feed clean
mouse packets to the X server.

===============

Follow up with;
http://www.linuxjournal.com/article/1090
http://www.linuxjournal.com/article/4600

I used the keywords "mouse redhat" to locate these articles, via the
search function on their pages.

I have the book, Linux Device Drivers, 2d ed., and noticed that its index
doesn't mention mice. If there is some place in that book that would have
helped me with this question, I'd also like to know that. I did find a file
named mouse_drv.o and tried, in text mode and as root, to install it with
insmod, but got an error message about how it couldn't determine which kernel
it had been compiled with. I'll see if I can find the source to mouse_drv.o
to see what it nominally does.

I'm running a 2.6.8-3-686 kernel on Debian, and recently did 2 full
dist-upgrades all the way from Sarge to Sid -- well Sid broke my X, and
installed Xorg and Udev, which really messed up my keyboard and mouse,
so much so, that X would NOT start at all. The answer (partly) for me
was to uninstall "Udev" and reinstall "Hotplug". I could have spent
mucho time reconfiguring and trying to figure how Udev works, but it
was too much for me to worry about it on a non-working dual boot
system. I just needed X to start working again...

Point is...
Better start learning how the kernel modules work, how they're compiled
(and/or loaded), what hotplug, udev, devfs, etc are and how they relate
to *your* installed kernel (I'd suspect perhaps 2.2?), and what changes
(big) will occur if and when you upgrade.

Regards

.

Relevant Pages