This is irrelevant. The "housekeeping data" is actually 13 bytes. The speed of the interface is 1.5Mb/sec. I am not even going to bother working out how much time that takes (or indeed the full data packet) to be sent over the wire as its so short to be unimportant. Its much shorter than the time taken for one PS/2 keypress to be sent.
Again, the 1.5 Mbs is the
theoretical maximum for a "low-speed USB" device. Most "low-speed" devices don't operate anywhere near that speed, nor are they required to in order to meet spec. What would be required to know what can absolutely be expected from a "low-speed" device would be a "minimum speed" specification, which I can't seem to find.
It's important to note that the keyboards PS/2 bus is dedicated only to a single keyboard, so it doesn't require the scads of bandwidth USB needs to share amongst all of the other devices it can have attached to it. Several hundred keyspresses per second can be streamed over the PS/2 bus, so bandwidth isn't an issue.
I am not sure what you mean here. The only place that interrupts figure in PS/2 protocol where the keyboard controller on the motherboard would be allocated an interrupt on the CPU. The keyboard controller is now buried in the motherboard chipset and does not have its own interrupt, but shares interrupts and logic with other on-board functions. The direct nature of PS/2 went out some time ago, along with hot-pluggability.
Sorry I wasn't clear. Unlike USB, the PS/2 bus is "quiet" unless something has changed at the inputs, or in the rare event that the PC wants to send something like LED states to the keyboard.. The interrupt I was referring to is the one triggered at the chipset when the device (keyboard encoder) signals that it has data to send, so it is serviced quite quickly and efficiently. Just because the functionality is buried in a chipset doesn't change the way it operates.
Also, to my knowledge hot-plugability was never part of the PS/2 spec. so it couldn't really have "gone out". But it has been pretty safe to do with anything manufactured for the last 5-6 years now. If anything, it's something somewhat recent for PS/2
On a side note, another issue I've seen written regarding USB key reports is that the individual keys in the same report can't be counted on being processed in any particular order. As the data is delivered in packetized form, the host processes it in any order it wishes. This could give one player an inappropriate "victory" over another if the two press their buttons within the same polling interval. USB sends
multiple-key state packets serially, while PS/2 sends
individual keypress states serially. While this would probably only be a possible issue with a head-to-head type game between two human players, it's still a difference in the way the input data appears to be handled.
This is incorrect. I could post a screen shot from a USB bus analyzer which shows that when 2 endpoints are used, each endpoint is alternately polled at 3.5ms intervals.
Is this screen shot from your combo device or a generic one?
Where do you get 37ms from? I thought it was agreed that the latency is 7ms. There is no significant additional latency involved. De-bounce is not applicable on the initial key-down transition.
Again, sorry for not being more clear. The next same keypress sent would take 30ms, plus whatever time was left before the next poll, up to an additional 7ms. Agreed that this is probably not much of an issue for most games. But while nobody could sustain constant firing at that rate, very short and quickly repeated bursts with a leaf-switch based button could be a different story. There are also non-gaming applications (machine control, pulse counting, etc) where cycling of the inputs can and does happen at intervals shorter than 30ms. Again, a PS/2 KeyWiz can have it's inputs cycled, on average, 4-5 times faster.
But as you said, much of the difference is "nuance" and if the user is happy with the way things are functioning for them during installation and gameplay, little else matters.
RandyT