mouse problems

H

holmslaw

I have a laptop and a fuji siemens desktop about 5 years old running windows xp home. With the laptop I use a "Microsoft notebook optical mouse 3000" and it also works with the desktop.

However I have 3 other mice that all work with the laptop, but they won't work with the desktop. One of them brings up a warning that the device is malfunctioning. And the other 2 do nothing, don't even get the usual new hardware detected notice, eventhough I have correctly set up the mouse properties. And I have tried 3 different usb ports.

Does anyone know whats going on, Thanks
 
Sponsored Links
Have you got your mother board chipset drivers installed?

If you know the make and model of your motherboard then we can point you in the right direction.
 
Have you got your mother board chipset drivers installed?

All I can say is that everything used to work, so the answer must be yes.

If you know the make and model of your motherboard then we can point you in the right direction.

The mobo is an Asus P5GD1-FM (FSC OEM)

since my original post, I deleted all mouse drivers and the desktop know recognises another of the mice as "HID compliant mouse" and it works ok.

So I still have 2 mice that are not recognised.
 
Well, you have ruled out the mice as being at fault, if the ports on the PC work with other devices such as data storage keys, then it won't be hardware. So that leaves software. If its that important to get the mice working, you could try a windows restore to reinstall the basics. A full destructive recovery will defo clear a software fault, but drastic for a mouse.

The simple thing, get a little green USB to PS2 converter...
 
Sponsored Links
I was mainly concerned that it could have been a mobo problem.

So I downloaded a bootable version of ubuntu and all the mice worked with it. So seems to me I've proved that its an xp problem and the solution is to reinstall xp.

Would others agree?
 
Actually I don't think we have ruled out the usb driver issue as a mass storage device such as a usb key is different to a HID (Human Input Device) such as a mouse/keyboard.
 
Sorry need to go out tonight, but basically the motherboard is actually part of Fujitsu Siemens, so you need to look for a chipset driver for the P5GD1-FM. Id start at the fujitsu website.

It will be called chipset driver (probably intel inf file) and this contains the device information for the USB PCI-DEV.
 
And neither driver comes from a chipset manufacturer. Installing drivers at random is not the solution.
 
Umm having coded USB drivers for a leading manufacturer I can almost certainly say that do generally get contained within a chipset driver INF.

PCI, AGP, USB and PnP are generally contained within a generic chipset driver package. The USB, PCI etc is south bridge and AGP generally north bridge and this information for driver details is stored in the chipset driver inf (files).

The old ISA mapping was , in the majority, stored within the chipset driver set as well.

A destructive restore of XP, unless from the OEM recovery cd will just lead to more problems as the chipset driver and others (audio bus, SMBus, optimised graphics, wifi, lan etc) won't be included, or not offer the full support. Wifi Intel drivers do not offer LEAP support with the windows WDM driver for example and only offer this with the Intel ProSet package or the Cisco Client.

Perhaps I was dreaming when I coded these, and the package wrapper?
 
Umm having coded USB drivers for a leading manufacturer I can almost certainly say that do generally get contained within a chipset driver INF.

Do you know what OHCI (actually there's two of those, but one isn't USB), UHCI, EHCI, and xHCI are?

Also AHCI, although that's not USB.

And are you aware that USB device class drivers are totally independent of USB bus drivers?
 
Open Host, Universal Host, Enhanced Host, and Extensible Host are different standards of interface level api's/protocols.

also the USB class driver is not totally independent from the bus "driver" in a programming point of view.
 
Open Host, Universal Host, Enhanced Host, and Extensible Host are different standards of interface level api's/protocols.

also the USB class driver is not totally independent from the bus "driver" in a programming point of view.

It's independent in that it doesn't give a flying monkey whether you're using an OHCI, UHCI, or EHCI controller. That's for the OHCI, UHCI, or EHCI driver to deal with.

Now are you suggesting he has some sort of ultra-rare non-OHCI/UHCI/EHCI USB controller which somehow works with some mice and not others for some totally unfathomable reason?

Would it also randomly fail to work with USB hubs which, like HID devices, all use the same class driver?
 
I assume form your last point that you were insinuating that I was implying that the USB device class driver was the one and the same as the USB "bus" driver.

They aren't, however they are not totally independent.
 
Open Host, Universal Host, Enhanced Host, and Extensible Host are different standards of interface level api's/protocols.

also the USB class driver is not totally independent from the bus "driver" in a programming point of view.

It's independent in that it doesn't give a flying monkey whether you're using an OHCI, UHCI, or EHCI controller. That's for the OHCI, UHCI, or EHCI driver to deal with.

Now are you suggesting he has some sort of ultra-rare non-OHCI/UHCI/EHCI USB controller which somehow works with some mice and not others for some totally unfathomable reason?

Would it also randomly fail to work with USB hubs which, like HID devices, all use the same class driver?

If the USB "Controller" cannot interpret the USB "device" then possibly, Ive seen such.

If the USB Controller default driver (for what Windows WDM this is the relevant interface) does not support some proprietary information exchange that the chipset manufacturer has included then you will get mis-communication between the bus and the device.
 
Open Host, Universal Host, Enhanced Host, and Extensible Host are different standards of interface level api's/protocols.

also the USB class driver is not totally independent from the bus "driver" in a programming point of view.

It's independent in that it doesn't give a flying monkey whether you're using an OHCI, UHCI, or EHCI controller. That's for the OHCI, UHCI, or EHCI driver to deal with.

Now are you suggesting he has some sort of ultra-rare non-OHCI/UHCI/EHCI USB controller which somehow works with some mice and not others for some totally unfathomable reason?

Would it also randomly fail to work with USB hubs which, like HID devices, all use the same class driver?

If the USB "Controller" cannot interpret the USB "device" then possibly, Ive seen such.

If the USB Controller default driver (for what Windows WDM this is the relevant interface) does not support some proprietary information exchange that the chipset manufacturer has included then you will get mis-communication between the bus and the device.

They're all HID devices, aren't they? Why are some special?

As for the latter case, avoiding that occuring is the entire reason that open standards such as OHCI and EHCI were developed. They are well defined and either work or do not. If you work for a company which produces a host controller which claims to support such an interface but fails to work with a standard driver, it is non-compliant and I would VERY much like to know the name of the company and the details of the device, so I can expose them for the incompetent buffoons they are.
 
Sponsored Links
Back
Top