Originally posted by: Peter
Before the "PS/2 has adjustable poll rate" misconception turns up again: USB is a busmaster device on a fast chipset internal connection (faster than PCI), while PS/2 is on the ancient AT keyboard controller (an 8-bit ISA device).
Isn't the USB functionality provided by the vast majority of the chipsets out there, on the southbridge? Also, on my Via KT400/8235, at least, it's not in the least bit busmastering, it's PIO-driven. Second, there is no physical AT keyboard controller anymore, it's also integrated into the chipset, I'm guessing with the LPC I/O functionality, so it doesn't have exactly the same sorts of performance disadvantages that a real 8-bit ISA device would have. In short, both are chipset-internal in the southbridge on current machines, so both should have similar performance.
Originally posted by: Peter
This is why PS/2 needs that poll rate adjustment to keep balance between hogging the system busses for too long and making the mouse too jerky. USB lets you have a smoothly moving mouse cursor without using much bus time.
I've never, ever, seen a PS/2 mouse take up an excessive amount of CPU time. I would argue that exact opposite - with a (usually dedicated) IRQ line, and a much smaller software stack in the OS to handle PS/2 port activity, it is overall far more efficient than USB for input devices. USB has multiple levels of device-drivers, including some user-mode components that need to process the data (HIDSRV), and the latency involved for the OS to schedule all of those threads before the input is fully-processed - on a heavily-loaded machine, I find USB mice to lag and skip a lot, although that may be due to my PIO-mode USB chipset too. Even on a chipset that supported bus-master USB ports, even if the hardware is able to read the data in a fraction of time, if the system still has to wait to schedule a lower-priority user-mode process in order to "cook" the data before use, then it will still lag. This same phenomenon can also be observed with PS/2 mice, if one installs Logitech's MouseWare software, which allows re-mapping buttons, etc. The additional software-stack overhead is noticeable to gamers.
The original reason for allowing adjustment of the AT keyboard microcontroller's clock speed, was to overclock it and increase peformance (due to the discrete keyboard microcontroller being somewhat slow in executing/intepreting commands), it had nothing to do with bus utilization, which is utterly trivial. If you want to talk about wasteful bus utilization, how about onboard AC'97 audio chipsets that don't use bus-mastering, or only have a buffer the size of a single CPU cacheline, leading to "skippy" audio whenever something slightly CPU-heavy is being run, and the fact that it needs to be "fed" so often, precludes doing large PCI burst transfers over the same bus.
(Heck, even ISA sound cards had at least a small internal sound-buffer FIFO, even if they weren't DMA-driven themselves.)