> Apple could've used something similar to PS/2 but increased the clock rate to whatever they needed, and it'd still look the same and be compatible to existing software.
If you deliver a byte per interrupt to be compatible with PS/2 then your system has to wake up more frequently than a DMA/SPI interface.
> USB … is a polled bus
> PS/2 is interrupt-driven and low-power enough for me.
This is wrong.
USB and PS/2 both deliver an interrupt when there is data available.
USB can be configured to directly store the data in memory, so that in the ISR the operating system simply scans memory.
PS/2 on the other hand has to be polled inside the ISR, whether there is data available or not. Not a problem for a keyboard, but touchpads send a lot of data (of course, this is why everyone uses SPI for touchpads)
> It really doesn't matter what the physical interface on a laptop is, since the software interface is what's important here
This is a common, but fundamental misunderstanding of how software and hardware work.
Hardware is not mere programmable matter, it has wires and current, and those wires take up space, and that current draws down your battery.
A lot of laptop vendors have to include "compatibility chips" that take up space and draw down battery because they don't control the software, but if they did control the software they could make their users happier.
If you deliver a byte per interrupt to be compatible with PS/2 then your system has to wake up more frequently than a DMA/SPI interface.
Nothing says Apple couldn't just add DMA capabilities to a PS/2 controller, sort of like how bus-master IDE works.
USB can be configured to directly store the data in memory, so that in the ISR the operating system simply scans memory.
That's just DMA, but the USB controller itself has to physically poll the bus. (Excepting some features in USB 3.x, which I don't think I've seen any use of currently for keyboards or mouses.)
PS/2 on the other hand has to be polled inside the ISR, whether there is data available or not. Not a problem for a keyboard, but touchpads send a lot of data (of course, this is why everyone uses SPI for touchpads)
If I remember correctly, the polling is only necessary for writing commands to the controller+device, and not the usual reading of data. 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.
A lot of laptop vendors have to include "compatibility chips" that take up space and draw down battery because they don't control the software, but if they did control the software they could make their users happier.
"compatibility chips" - such as?
Hardware is not mere programmable matter, it has wires and current, and those wires take up space, and that current draws down your battery.
The amount of processing required for a USB stack is far greater than for PS/2 and presumably Apple's custom SPI solution. 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.
...and that obviously many users here are not "happier" because of it, but Apple doesn't care.
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.
FTFA.
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.
You must wait for inb(0x64) & 1 before reading from 0x60.
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.
If you deliver a byte per interrupt to be compatible with PS/2 then your system has to wake up more frequently than a DMA/SPI interface.
> USB … is a polled bus
> PS/2 is interrupt-driven and low-power enough for me.
This is wrong.
USB and PS/2 both deliver an interrupt when there is data available.
USB can be configured to directly store the data in memory, so that in the ISR the operating system simply scans memory.
PS/2 on the other hand has to be polled inside the ISR, whether there is data available or not. Not a problem for a keyboard, but touchpads send a lot of data (of course, this is why everyone uses SPI for touchpads)
> It really doesn't matter what the physical interface on a laptop is, since the software interface is what's important here
This is a common, but fundamental misunderstanding of how software and hardware work.
Hardware is not mere programmable matter, it has wires and current, and those wires take up space, and that current draws down your battery.
A lot of laptop vendors have to include "compatibility chips" that take up space and draw down battery because they don't control the software, but if they did control the software they could make their users happier.