> That's just DMA, but the USB controller itself has to physically poll the bus.
Who cares? The USB controller requires a fraction of the power that the CPU does.
If I have to choose between a microcontroller polling for "interrupt endpoints" and the CPU, you know what I'm going to choose.
> If I remember correctly, the polling is only necessary for writing commands to the controller+device, and not the usual reading of data.
No. You must wait for inb(0x64) & 1 before reading from 0x60. Note this dance is actually quite long:
It's probably okay for a keyboard and a low-resolution mouse. Maybe. It's definitely not okay for a touchpad.
> There are plenty of touchpads that use PS/2 as well, and they usually appear to be mouses until switched to a different protocol mode.
With extra chips.
I think the main point to take away from all this discussion is that although Apple could've taken an existing widespread and compatible interface with similar characteristics and enhanced it to fit their requirements, they didn't because it was more expensive.
You might think some people want Apple laptops to be hacker friendly, and you might be right, but my point is that you should consider that some people would rather they be cheaper and lighter and more power efficient.
The code clearly shows that all the ISR does is read from the status port, and if there is data available, read it from the data port. It only does nothing in the unlikely case that no data is available (could be a spurious interrupt.) I have written code like this before. There is no waiting, no polling. Receive an interrupt, read a byte. Some devices will actually let you read multiple bytes (just keep reading until one of the bits in the status register goes off.)
You're claiming it would significantly increase cost to enhance an existing interface (as opposed to redesigning everything and the nontrivial NRE of that?), on a laptop that itself costs far more than the majority of others using a standard or slightly enhanced standard interface.