Is the difference due to changes in the operating system or is it due to differences in hardware usb vs ps/2 inputs?

Mainly due to hardware :

- USB works by polling for changes at fixed intervals

- ps/2 works with interrupts, so the OS will know immediately when hw does something.

What about USB mice with 250-1000Hz polling rate. I can't imagine it's still a problem.

I might even argue that it’s a worse problem.

A kid who asks you 1000 times a second whether you are there yet is going to know within 1ms of when you get there, but I imagine we’d all like being the driver much more if there were no “are we there yet”s and all the kid needed was one “We’re here” exactly when you arrive.

There is in fact an interrupt mechanism for input devices - the host sends a request with a long timeout and the device responds to the outstanding request when it has something exciting to report, or when the timeout is about to expire. This is used frequently in low input rate devices like keyboards. Gaming mice use a high polling rate because it saves you the effort of keeping track of outstanding requests - you just report your current state immediately on every request, and the driver end can decide how often to ask you.

I may need to update my knowledge (I hope I do if you’re right), but from my understanding USB is a CPU-emulated protocol, which is to say there are no pins for “mouse button”, and the CPU has to do some “figuring out what this data means” work for each input event. Then, all this is done on a multitasking CPU that may or may not prioritize the interpretation and processing of that input.

That all being true, having a publish/subscribe model is still not the same as having a true interrupt (and I’d have to do some digging to figure out whether there wasn’t still polling somewhere in the pub/sub pipeline)

While this is intuitively obvious, it doesn't really always play out that way in practice since interrupts can be expensive to handle. For example polled IO can be significantly lower latency than waiting for interrupts.

You’ve piqued my curiosity. Please explain.

Essentially you're spinning waiting for the event that you know must come. Your latency will be on the order of a few clock cycles. Whereas if you use interrupts you are always at least a state-save and state-restore underway before you can service the next event, and likely a lot more than that.

The difference is real time control of stepper motors with crazy speeds when microstepping at 300K steps / second or more interpolating across 5 axis vs moving them at a snails pace of maybe 10K steps / second (on really nice and otherwise idle hardware, miss a single step and your goose is cooked, now you have a cumulative error).

I thought I'd seen a rather dramatic benchmark of this but I can't find it now. (I think it was in the context of io_uring, whose documentation mentions that polled IO is much lower latency and I'd trust Jens Axeboe on that one.)

This intuitively makes sense especially with SSDs and especially with NVMe SSDs: you're not going to have to wait that long, especially compared to the overhead of an interrupt. Also, if you're reading sequentially, once you get one I/O completion you're going to get a lot more in a short timeframe—it makes sense to just poll for those instead of handling every one as an interrupt. Interrupts are pretty expensive (I honestly don't have a good grasp of how Linux interrupt handling works but it can easily be on the order of microseconds.)

It also has some side benefits like preventing the CPU from going into a lower power state for only a short period of time.

As I understand it, USB2 drivers don’t actually poll — the host controller chip polls the mouse. On USB3, there’s a real interrupt mechanism.

Does a serial port poll or interrupt?

If it’s possible to interrupt on a serial port, are there existing examples of how to configure a mouse or keyboard to interrupt over a serial port?

Depends on how you configure the chip. You don't actually need a chip, you can bit-bang serial just fine if you have accurate enough timing.

Typically a serial port would contain a small buffer which would fill up, upon completion of the first byte an interrupt would be generated and you'd respond to that and read out the register freeing up room for more bytes to be received. Transmit the same but reversed, as soon as a byte had left the shifter in the chip it would generate an interrupt so you could re-use that space for more bytes to send.

This works quite well. Hardware flow control can help in case the OS doesn't respond fast enough to the interrupts, so you don't lose characters.

It can do both, but I believe you need hardware flow control working to get proper interrupt behavior for that. I don't think any mice actually did it that way back in the day.

All serial chips that I'm familiar with since the 8 bit days would do interrupts, the only time that I worked without is when we were just using GPIO pins to emulate serial ports.