[lug] USB mouse w/ Red Hat 7-Newbie Question

D. Stimits stimits at idcomm.com
Wed Oct 10 06:04:35 MDT 2001


Ian Vaughn Bevan wrote:
> 
> I have not had a chance to mess with this until tonight, and have encountered
> another problem. I have all the modules (hid, input, mousedev) and loaded them
> through insmod, but when I reboot and lsmod they are not there. This is
> probably a basic newbie question, but is there a configuration file that I am
> missing here? How do I get the modules to load when I boot?
> 
> Ian Bevan                                Ian.Bevan at colorado.edu
> Information Technology Services          303.887.9223
> University of Colorado
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug

My file locations should be assumed for Redhat, your mileage may vary.

Each device (including mice) has a device special file in /dev/. Often a
common name like "mouse" is a symbolic link to a more technical hard
link file, e.g., /dev/psaux for PS2 mice, or /dev/ttyS0 for a serial
mouse on the first serial port. I don't know what device is used for USB
mice, but whatever it is, substitute that for the description.

Each device has a major number and a minor number (use "ls -l" on on of
them to see). The major number corresponds to either a kernel module or
compiled in kernel support of some feature. Minor numbers are for
specific devices, e.g., a single IDE controller might have /dev/hda1 and
/dev/hda2. The major/minor for those are 3,1 and 3,2. So some kernel
module or compiled in support provides major number 3 support, and hda1
and hda2 are two specific instances of that use. Note that /dev/hda is
the drive as a whole, and hda1, hda2, so on, are partitions...instances
of pieces of the drive...their minor numbers vary, but major is
consistent.

If you monitor /var/log/messages (e.g., tail -f /var/log/messages), and
you attempt to read or write to a major number device special file
without support (e.g., try "cat /dev/sdbs3" while watching, look for
block-major-68 failure notice), it'll show up there as an error message.
Before it shows up as an error though, the kernel module loader will
attempt to find a suitable module. If a suitable module shows up, it
will continue, else an error.

Trick #1 is that a given device might require more than one module,
beyond major number support, e.g., joystick support often requires
generic joystick module (the major number support, joydev), game port
support (module gameport), a pci module (since the port is pci, this is
ns558), and finally a module specific to analog joysticks (module
analog). Only the joydev module provides major number support. Only lack
of major number support will trigger a search for a module for the
joystick. Had you compiled support for joydev directly into the kernel,
and NOT as a module, all further modules would have to be loaded by
hand. The first module that loads can trigger dependency checking in
/etc/modules.conf, regardless of which module it is.../etc/modules.conf
doesn't care about major number. But only the joydev module is
autoloaded in the joystick support, because it is the one with major
number support.

If you do not have a module to provide the major number support of your
USB mouse, and it is also not compiled in, it will not autoload (kernel
must detect lack of major number support to try modules). If you have
support for the major number as a non-module, it will not autoload,
although loading of all further related modules by hand will cause
success. I do not know which module provides support for your USB
mouse's major number, but my guess is that you have it compiled directly
into the kernel, not as a module.

One note on making this support as a module, be careful not to
modularize anything required for boot. For example, if you were to make
ext2 a module, and the module itself is located on ext2 partition, you
have a chicken-and-egg dilemma. In that case you'd have to put it in an
initial ramdisk (mkinitrd).

Now if all this is correct, and you do not want to recompile your kernel
for autoloading to work right, you can add the insmod or modprobe it in
/etc/rc.d/rc.local.

D. Stimits, stimits at idcomm.com



More information about the LUG mailing list