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

Using applications, configuring, problems
Message
Author
John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

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

#21 Post by 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?

pakt wrote:(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
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

USB CLASS ID's

#22 Post by 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.
Last edited by John Doe on Mon 11 Dec 2006, 02:57, edited 1 time in total.

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#23 Post by John Doe »

Vendors, devices and interfaces.

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

lesliek
Posts: 18
Joined: Thu 09 Nov 2006, 21:41

#24 Post by 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?

User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

Re: USB CLASS ID's

#25 Post by pakt »

John Doe wrote: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 :evil:
John Doe wrote:I'm still looking for the "master list", there must be one somewhere.
That makes two of us :!:
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#26 Post by John Doe »


User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

#27 Post by pakt »

John Doe wrote: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.
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

User avatar
Gn2
Posts: 943
Joined: Mon 16 Oct 2006, 05:33
Location: virtual - Veni vidi, nihil est adpulerit

#28 Post by 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.

User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

#29 Post by pakt »

lesliek wrote: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... :roll:
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

#30 Post by 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
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

#31 Post by 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

:P
Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

ricstef
Posts: 52
Joined: Wed 02 Aug 2006, 02:25
Location: Woodstock, ON. Canada

USB wireless mouse testing

#32 Post by 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. :D
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. :D

Richard.

User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

#33 Post by 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
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

John Doe
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

#34 Post by 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
Posts: 1681
Joined: Mon 01 Aug 2005, 04:46
Location: Michigan, US

USB Keyboard ZBoard Test Success.

#35 Post by John Doe »

IT WORKED!!

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

Great work Paul!

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#36 Post by BarryK »

Paul, this is really great, you've fixed the usb keyboard detection
problem as well! I've downloaded the latest rc.local0.gz.
Looks like a definite goer for Pup 2.13!

User avatar
Crash
Posts: 453
Joined: Fri 09 Dec 2005, 06:34
Location: Melbourne, FL

#37 Post by Crash »

I tested two different USB mice on two different computers. The mice are:

Microsoft Wireless Notebook Optical Mouse
Logitech Cordless Optical Mouse

The two computers are:

Soyo K7VMP motherboard homebrew, Athlon XP 2400+, KM400 chip set, 256MB RAM
E-Machine, Athlon 64 3200+, 1GB RAM

I disabled the hard drives in both computers, booting off two live version 2.12 CDs, one with the old version of rc.local0, one with the new version.

The new rc.local0 works fine with the Logitech mouse on the Soyo computer. USB Mouse Support can be either on or off in the BIOS setup.

The old rc.local0 does not work with the Logitech mouse on the Soyo computer.

On the Soyo computer, either the old or new rc.local0 works with Microsoft mouse. USB Mouse Support can be either on or off in the BIOS setup.

On the E-Machine, the Logitech mouse works with the new rc.local0 whether or not USB Legacy Support is enabled in BIOS.

The old rc.local0 does not work with the Logitech mouse on the E-Machine.

On the E-Machine, the Microsoft mouse works with either the old or new version, whether or not USB Legacy Support is enabled in BIOS.

In conclusion, the new rc.local0 results were completely positive for these tests.

User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

#38 Post by pakt »

Yes, I think this will be a reliable method for detecting USB mice and keyboards.

Many thanks to all the Puppy enthusiasts who tested and returned feedback :)

Paul
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

jairomacon
Posts: 3
Joined: Wed 21 Apr 2010, 13:51

#39 Post by jairomacon »

I switched to Puppy 2.12 recently. I was confused in problem with my USB mouse in it. using your tweaks I resolved It. I switched to Puppy 2.12 recently. I was confused in problem with my USB mouse in it. Using your tweaks I resolved it. Further I had a problem with it's detection,some power supply was laking in it. Then severally it was happened that mouse can't not work for a while & then it start working.
Where there is will there is way.

Post Reply