Paul, the bloody thing's just made a liar of me!
I turned the computer on a while ago and the mouse worked. I immediately created a document from the output of dmesg, on the theory that if the mouse doesn't work later, I'll be able to compare today's output with the later output to see what's changed.
I'll return to that in a moment, but a couple of incidental matters first: the kernel used by DSL is 2.4.26; that's a matter emphasised at its website. Next, Puppy 2.11 might see my USB mouse, but then I wouldn't have the audio driver needed by the MC Jr.
Now back to the main issue.
Is it at all possible that the working of the mouse could be affected by something as irrational as which of the USB ports you plug it into? When I booted up a while ago, I had it in the back USB port. I'm pretty sure that when I was trying to get it going yesterday, I didn't try that. I think I only tried the front two, simply because it was easier.
Next, I've studied my dmesg output as best I can. (I had some help from "dmesg explained", at
http://linuxgazette.net/issue59/nazario.html.)
I went looking for mouse stuff in particular. At one point, I found: "mice: PS/2 mouse device common for all mice". However, that (whatever it means) comes before a line that says: "VFS: Mounted root (ext2 filesystem) readonly", which is a significant point in the process, I believe.
After that, there's a reference to the freeing of some kernel memory and then comes "input: AT Translated Set 2 keyboard as /class/input/input0". So that's the keyboard taken care of.
Then comes a lot of USB stuff. There's talk of the drivers usbfs and hub, then some stuff about a USB hub's being found with 3 ports detected, then the driver hiddev.
After that, I get:
"input: USB Optical Mouse as /class/input/input1
input: USB HID v1.10 Mouse [USB Optical Mouse] on usb-0000:00:01.2-1"
Then, I get a reference to the new driver usbhid.
So it must be those two input lines I just quoted that showed that what was necessary for the mouse to work had happened.
I don't know whether any of the above gives you any useful information. If not, apologies. Also, if my whole output might be of any use, I'd happily post it.
Finally, on an entirely different topic, but arising from my reading through the dmesg output line by line.
There's a line in the output that says:
"ide: Assuming 33MHZ system bus speed for PIO modes; override with idebus=xx"
Does that suggest that some option chosen on booting up might make the computer run more quickly (in a way apparent to humans, I mean)?
Paul, you've really been doing a great deal of work about this mouse bizo. I'm certainly very grateful for it, as I know from their posts are others.
Thanks again,
Leslie
EDIT: In the time it took me to write the above, the following output was added to the original dmesg output:
usb 1-1: USB disconnect, address 2
usb 1-1: new low speed USB device using ohci_hcd and address 3
usb 1-1: configuration #1 chosen from 1 choice
input: USB Optical Mouse as /class/input/input2
input: USB HID v1.10 Mouse [USB Optical Mouse] on usb-0000:00:01.2-1
usb 1-1: USB disconnect, address 3
usb 1-1: new low speed USB device using ohci_hcd and address 4
usb 1-1: configuration #1 chosen from 1 choice
input: USB Optical Mouse as /class/input/input3
input: USB HID v1.10 Mouse [USB Optical Mouse] on usb-0000:00:01.2-1
usb 1-1: USB disconnect, address 4
ohci_hcd 0000:00:01.2: wakeup
usb 1-1: new low speed USB device using ohci_hcd and address 5
usb 1-1: configuration #1 chosen from 1 choice
input: USB Optical Mouse as /class/input/input4
input: USB HID v1.10 Mouse [USB Optical Mouse] on usb-0000:00:01.2-1
usb 1-1: USB disconnect, address 5
usb 1-1: new low speed USB device using ohci_hcd and address 6
usb 1-1: configuration #1 chosen from 1 choice
input: USB Optical Mouse as /class/input/input5
input: USB HID v1.10 Mouse [USB Optical Mouse] on usb-0000:00:01.2-1
So the mouse seems to be disconnecting and reconnecting at intervals (how great they are isn't said). Can that be usual?