On Mon, Apr 02, 2012 at 06:44:31PM +0100, Wayne Stallwood wrote:
If you grep the kernel logs or dmesg for the USB device it appears as after it has disconnected you should see some reason
OK, I'll look.
I am guessing the USB controller has blacklisted it for doing something strange. I think I have seen this happen before where the controller blacklists devices until the next reboot so unplugging and re-plugging won't work. The reason it works on the other sides ports is probably that you have more than one instance of the controller and the mouse hasn't been blacklisted on the other one yet.
I suspect if you leave it there for long enough the same thing will happen on that side.
You're right! It's tomorrow night now and the mouse doesn't work in the RHS USB socket.
I would suggest that if you look back for the disconnection event in the logs then you might get somewhere towards finding a reason.
Also when you plug it into the ports and it doesn't work is there any indication that it is powered up (say the equivalent of the LED under an optical mouse lighting up ?)
I think USB does a pretty good job as a generic low(ish) speed bus...Given the variety of devices it ended up supporting we could have ended up with something quite a bit more nasty or proprietary.
Physical issues I have with the connectors aside I think the implementation is ok, specialist interfaces can often do a better job but only for a fraction of devices USB has supported.
Yes, OK, USB isn't as bad as I make out.