Subject: Re: linux question
Mon Jun 08 18:22:02 1998



others have given the basic answer to this one.. i'm just here
for the color commentary.


> I've been trying for about 3 weeks to get my mouse working with
> XWindows. I think I've found the problem. 'mouseconfig' finds
> the mouse on cua1 whereas in my /dev directory is the file
> description mouse -> cua0. But since this isn't a file, I can't
> open it in vi and edit it.

two things:

1:  you're correct that the contents of the /dev directory
aren't normal files.. technically, they're known as 'nodes'.  
that's a funky way of saying that there's a piece of software
(the device driver) behind the scenes handling communication
with the device, but masquerading as part of the file tree.

one of unix's big selling points is that it treats everything
like a file.. hard drives, modems, parts of the CPU, you name
it.   the node convention is the curtain that hides the little
man who makes hardware i/o look like any other part of the
filesystem.   the contents of the /dev directory are where the
little man stashes his raw data, thus those items fall more
heavily in the "don't try this at home" category than other
parts of the file tree.   the geekspeke for this is that nodes
are 'special' files.

nodes are defined in terms of the amount of data which passes
through them at any given time.   hard drives are more efficient
if you keep a buffer of data the same size as a disk sector, and
only read or write that much data in a single shot.   thus,
drives are known as 'block special' files.   other devices, such
as the mouse, need to present small quantities of data in
real-time, so they're capable of being read one byte (the size
of a 'char' variable in C) at a time.   therefore, the mouse
node is a 'character special' file.


symbolic links are a useful way to put a simple, well-known name
on information which might need to hop from file to file.  it's
really just another piece of behind-the-curtain work.

basically, a symbolic link is a file that knows just enough to
be able to pass the buck to somebody else.   when the user goes
to the filesystem and says, "i need what's in /dev/mouse", the
OS pulls up that file, which in turn says, "oh, wait.. i'm just
a link.. the info you really want is over in /dev/cua0".   so
the OS locates *that* file, asks the little man behind the
curtain to read the data from it, and passes whatever it gets
back as a response to your original request.



in this particular case, /dev/mouse is a convenient name any
X-based program can use to find the character special file used
by the mouse driver.   the kernel has drivers for both serial
ports, but your version of /dev/mouse happened to be pointing to
the port the mouse /wasn't/ plugged into.    removing your
previous /dev/mouse and relinking it to /dev/cua1 sets up a
behind-the-curtain bank shot, letting anyone who needs to use
the mouse find the *correct* driver without having to play all
sorts of seriously ugly/nasty program-by-program configuration
games.



2:  you're using vi.. *snif*.. i'm so proud.   ;-)



> In /etc/sysconfig the mouse is correctly identified as
> MOUSETYPE="microsoft" (it's a normal MS serial mouse) followed
> by the line, 'XEMU3=no'. I've tried changing this to yes without
> any success, so changed it back to no.

just to beat the dead horse completely into the ground, the
MOUSETYPE variable tells the kernel to use a serial driver that
speaks the MS mouse protocol, and the XEMU3 variable tells it
whether you want to use 3-button emulation (clicking L & R at
the same time == clicking a conjectural 'center' button).  
neither one tells the system how to actually /find/ the mouse,
but full marks for looking, finding, and tinkering a little.



> What's the answer?

well, you had all the pieces right..look for references, play
with a few things, and if necessary, say "okay, i've RTFM and it
didn't help.. how make do/go?"

you'd be surprised how often this is the correct method.  ;-)