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).

lesliek wrote:

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._________________Puppy unofficial tester (off and on) since v0.9.2

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.

RichardLast edited by rerwin on Sun 10 Dec 2006, 19:34; edited 1 time in total

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.

(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.

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.

"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

John Doe wrote:

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

That makes two of us _________________Puppy unofficial tester (off and on) since v0.9.2

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._________________Puppy unofficial tester (off and on) since v0.9.2

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... _________________Puppy unofficial tester (off and on) since v0.9.2

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!)

Quote:

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!

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum