USB mouse not working in 2.12? Here's a solution

[pakt]

I understand why you've changed the rc.local0 script to search for "Cls=03(HID ) Sub=01 Prot=02" and, indeed, the new mouse I bought shows that very information when I run "cat /proc/bus/usb/devices". The only problem is that it doesn't show that information when I run that command on my MC Jr with Puppy. The device doesn't even appear in the list of USB devices, nor does it work generally.

On the other hand, that information does appear when I run the command on my MC Jr with Damn Small Linux. (I've put the latter on a bootable USB flash drive, my Puppy being on the CF drive.) Also, the mouse works normally in DSL.

Leslie, I understand what you're saying about your new mouse not appearing in the output of 'cat /proc/bus/usb/devices' on your MCjr - I also have such a mouse (a Labtec Optical Mouse). That it does appear when you run DSL on the MCjr tells me that there is a USB bug in the 2.6.18.1 kernel. I'm quite certain DSL is using a different kernel (type 'uname -a' in a terminal to find out).

I really have no skill or knowledge in these matters, so I can only approach this very simplistically, but it seems obvious that, at the moment at which the rc.local0 script is run, the OS is not yet aware that it has a mouse hanging off the computer. It must know (or be capable of knowing) that it's got some kind of USB device there, because the mouse is getting power through the USB port (the mouse is lit up from the moment I turn on the computer), but it isn't able to get the necessary information to identify it as a USB mouse.

Yes, I believe you are right in your analysis that the OS is not aware of the connected mouse, but it would get power anyway as soon as it is connected - there is always 5V out from the USB connector when the PC is turned on. It's just the OS software that's not working correctly.

Unfortuately, if '/proc/bus/usb/devices' doesn't show the mouse (and it doesn't appear in 'dmesg' either) then AFAIK there is nothing you can do to have Puppy 2.12 automatically find it. The mouse is, for all practical purposes, invisible to Puppy

I haven't tried it yet, but it might be interesting to see if Puppy 2.11 'sees' the mouse on you MCjr - it uses an earlier kernel.

[pakt]

This morning the upgraded script didn't load the usbhid module during bootup.

zigbert, please check /etc/rc.d/rc.local0 and see if your modification survived re-booting in case the file was not saved to pup_save.3fs.

Also check that you have two spaces between "HID" and ")" on the new line.

[rerwin]

Re weird wireless USB mouse behavior:

Did you have this problem before using the modified rc.local0?

This was the first time I tried my USB mouse with Puppy (or any other linux). It works very snappily on another PC, 450MHz, 256MB, WinXP.

I just now tried it on an Xubuntu PC, 466MHz x 2, 256MB where it is also very snappy and behaves as one expects.

UPDATE: I just tried the mouse with Puppy on those other 2 PCs and it worked normally on both, with and without your fix! The Aptiva must just have a primitive implementation of USB support. So it appears that some old PCs may not fully handle a USB mouse, but Puppy is OK. And I must have been mistaken when I thought the mouse didn't work in the Aptiva without the fix - the old local0 detects "Mouse" in the product line.

Richard

[zigbert]

zigbert, please check /etc/rc.d/rc.local0 and see if your modification survived re-booting in case the file was not saved to pup_save.3fs.

Also check that you have two spaces between "HID" and ")" on the new line.

Everything in my /etc/rc.d/rc.local0 seems ok (upgraded).

Like before my usb-mouse is sometimes detected, sometimes not, so I put "modprobe usbhid" in /etc/rc.d/rc.local. One thing seems to be better with your patch. Before, I had to replug my usb-mouse if it was not detected during boot. That issue is gone.

[Kal]

Feedback: We have just tried your latest download on both machines and they both work. We had an anxious moment until we played with the permissions, then it worked correctly.
Good Luck, Kal, Duke

PS: We were using Konqueror on one of the machines and did not see the permissions until we went to rox.

[John Doe]

Now that the zdrive has all the drivers, It looks like one can add PocketPC support to puppy the same way (at least load the kernel driver).

http://synce.sourceforge.net/synce/howto.php

I have tested the following. It functions correctly.

Code: Select all

#!/bin/sh

USBIPAQ=no

[ ! "`cat /proc/bus/usb/devices 2>/dev/null | grep -i "Cls=ff(vend.) Sub=ff Prot=ff"`" = "" ] && USBIPAQ="yes"

if [ "$USBIPAQ" = "yes" ];then
echo "Found PocketPC."
echo "Loading IPAQ Driver."
modprobe ipaq
fi

Is this part about keyboards being considered for inclusion also?

(Note that, in the same way, 'Cls=03(HID ) Sub=01 Prot=01' appears to be reserved for USB keyboards.)

I have a friend with a USB keyboard called a ZBoard (http://www.ideazon.com/us/) which has never worked with puppy. I wouldn't assume that the special functions would work, but just the base keyboard would be cool to have.

[John Doe]

Found this on wikipedia (about a third down the page)

"Each class also optionally supports a SubClass and Protocol subdefinition."

http://en.wikipedia.org/wiki/USB

Thought it might help also, for any additional USB research. I'm still looking for the "master list", there must be one somewhere.

-------------

The most used device classes (grouped by assigned class ID) are:

0x00
Reserved value - used in the device descriptor to signify that the interface descriptor holds the device class identifier for each interface.
0x01
USB audio device class, sound card-like devices.
0x02
USB communications device class used for modems, network cards, ISDN connections, Fax.
0x03
USB human interface device class ("HID"), keyboards, mice, etc.
0x06
Still image capture device class, identical to the Picture Transfer Protocol as used across USB
0x07
USB printer device class, printer-like devices.
0x08
USB mass storage device class used for flash drives, portable hard drives, memory card readers, digital cameras, digital audio players etc. This device class presents the device as a block device (almost always used to store a file system).
0x09
USB hubs.
0x0E
USB video device class, webcam-like devices, motion image capture devices.
0xE0
Wireless controllers, for example Bluetooth dongles.
0xFF
Custom device class - used to establish that a device or interface does not support any standard device class and requires custom drivers.

[John Doe]

Vendors, devices and interfaces.

http://www.linux-usb.org/usb.ids

[lesliek]

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?

[pakt]

Found this on wikipedia (about a third down the page)

"Each class also optionally supports a SubClass and Protocol subdefinition."

http://en.wikipedia.org/wiki/USB

Thought it might help also, for any additional USB research.

Yes, I saw that page. Unfortunately there is no information nor any links that lead to any listing of 'SubClass and Protocol subdefinition' for each 'Device class' - just links that lead to a quagmire of USB programming details

I'm still looking for the "master list", there must be one somewhere.

That makes two of us

[John Doe]

I THINK I FOUND IT!!!

http://www.usb.org/developers/defined_class

[pakt]

I THINK I FOUND IT!!!

http://www.usb.org/developers/defined_class

Nice try, John, but I've seen that too

Doesn't really say very much more:

Base Class 03h (HID – Human Interface Device)

This base class is defined for devices that conform to the HID Device Class Specification found on the USB-IF website. That specification defines the usable set of SubClass and Protocol values. Values outside of that defined spec are reserved. These class codes can only be used in Interface Descriptors.

Base Class SubClass Protocol Meaning
03h xxh xxh HID device class

What we want is a specific listing of 'SubClass and Protocol' that matches to different catagories of hardware (mouse, keyboard, etc)...

I've also checked the 'HID Device Class Specification' on the 'USB-IF website' referenced above, but that just led to a maze of programming detail... <sigh>

If you google the web with the search string "Cls=03(HID ) Sub=01 Prot=02" (with or without the two spaces), you'll find quite a few hits and they all reference USB mice.

I think we can be fairly safe in assuming that that string can be used in Puppy to detect USB mice.

It is certainly better than relying on the uncertain presence of the 'S:' string(s). And even if they are present, they don't neccessarily contain the search words (mouse, trackball, ad infinitum) that the script looks for.

[Gn2]

ide: Assuming 33MHZ system bus speed for PIO modes; override with idebus=xx"

= Setting basic motherboard bus In/Out data transfer rate
Usually doubled to clock at 66Mhz (see Bios options)

UDMA rating of drives determines burst speeds available.

Code: Select all

man hdparm

Nothing to do w/USB detections.
Which is initrd scripted by distribution developer.

[pakt]

So the mouse seems to be disconnecting and reconnecting at intervals (how great they are isn't said). Can that be usual?

lesliek, SiS (manufacturer of the System-on-chip that almost makes up the complete MCjr PC) have integrated their own USB controller in the chip. I believe this is the source of the problems. I think the Linux kernel is having problems 'conversing' with this controller, at least when it comes to certain mice. That would explain why those mice don't show up in 'cat /proc/bus/usb/devices'.

Since I have such an 'invisible' mouse (to the MCjr only), I will try some more tests. But I will do this later - I'm rather tired of this mess at the moment - I've been answering questions on the forum for the last four hours now and I'm tired...

[pakt]

Ok, I've done some more research on the MCjr's USB controller. It is a 'SiS 7001 OHCI' USB controller and there are issues with this hardware.

This page: http://www.usbman.com/Guides/SiS%20USB% ... Tricks.htm
notes

The SiS PCI/USB Host Controller can be difficult to configure and seemingly unrelated BIOS settings can adversely effect its operation. This is especially true of the 7001. Most older SiS motherboards suffer from USB issues.

According to the same page, even M*soft has had problems with this controller (and they have the manufacturer's full cooperation!)

The SiS 7001 has Known Issues with Windows XP that the New Registry Patch does not correct. Consider installing a PCI USB Card as a work around for the onboard USB host controller.

I think we can stop blaming Linux, and Puppy specifically, for the problems some mice have with the MCjr.

My advice, if you want a mouse that will work with the MCjr, is to get a Logitech Optical Mouse (the simple model with a scroll wheel). They are inexpensive and work with all the hardware I've tested so far - including the MCjr!

Paul

[pakt]

* FINALLY FOUND AN OFFICIAL DOCUMENT *

Ok, here it is: 'Device Class Definition for Human Interface Devices (HID)' on the USB Implementor's Forum: http://www.usb.org/developers/devclass_docs/HID1_11.pdf

To detect the keyboard:

Page 67: E.3 Interface Descriptor (Keyboard)
Class code (HID code assigned by USB) 0x03
Subclass code 0x01
Protocol code 0x01

To detect the mouse:

Page 70: E.7 Interface Descriptor (Mouse)
Class code (HID code assigned by USB) 0x03
Subclass code 0x01
Protocol code 0x02


Paul

[ricstef]

Paul,
My m$ wireless USB mouse worked fine before but I applied your change anyway just to confirm your excellent work. So it was no surprise to me that the mouse worked just fine after rebooting.
However, knowing what can happen if I ASSUME that the change took effect, I proceeded to verify that the present version of /etc/rc.d/rc.local0 indeed contained your change at line 192 ... YES ... it did !!!

Nice work, Paul.

Richard.

[pakt]

For those wishing to test both USB keyboard and USB mouse detection using the Class/Subclass/Protocol method, I have added a second modified rc.local0 file as an attachment to the first post in this thread.

Paul

[John Doe]

Just remastered a CD and I'm calling my friend in a couple minutes. I'll give you a post back after the "zboard" test.

I did just test a Dynex USB mouse that I have. It works great with the new method.

Will this stuff "plug-n-play" after it's all tested? i noticed it didn't just get recognized when I plugged it in, but only when it's booted. Does puppy have some type of loop somewhere or event that can load up drivers when USB connections are made? Maybe even a Load USB Devices button in the Wizards menu would be sufficient if the other option isn't available.

[John Doe]

IT WORKED!!

Puppy roared to life and the zboard worked, using the new method.

Great work Paul!