I see two possible causes for this. Either I have misunderstood you (as you state) and, moreover, continue to misunderstand you in the same way; or you have misunderstood me.
Both is also a possibility (and from my re-analysis seems to be the most likely.)
Allow me to abandon inferences about interpretations and just respond to some words.
Given that Clark constructed his own hardware he could easily make use of the full 2*log2(number of keys) bits of information per 33 bits of information by making his keyboard send only a keydown on the first keypress and a keyup on the second keypress (alternating).
That wouldn’t help;
This claim is false. It would help a lot! It improves bandwidth by a factor of a little under two over not the alternative making optimal use of the key_up signal as well as the key_downs. As for how much improvement the keyboard change is over merely using all 10 fingers optimally… the math gets complicated and is dependent on things like finger length.
I therefore note that replacing every keyup with a keydown saves a further 11 bits per 2 keystrokes, on average, for no loss of information.
I agree. If just abandoning key_up scancodes altogether is permitted then obviously do so! I used them because from what little I understand of the PS/2-keyboard protocol from reading CCC’s introduction then a little additional research the key_ups are not optional and decided that leaving them out would violate CCC’s assumptions. I was incidentally rather shocked at the way the protocol worked. 22 bits for a key_up? Why? That’s a terrible way to do it! (Charity suggests to me that bandwidth must not have been an efficient target of optimisation resources at the design time.)
Given that Clark constructed his own hardware he could easily make use of the full 2*log2(number of keys) bits of information per 33 bits of information by making his keyboard send only a keydown on the first keypress and a keyup on the second keypress (alternating).
That wouldn’t help;
This claim is false.
Yes, you are right. On re-reading and looking over this again, I see that misread you there; for some reason (even after I knew that misreading was likely) I read that as 2log2(number of keys) bits of information per keypress* instead of per 33 bits of information.
I agree. If just abandoning key_up scancodes altogether is permitted then obviously do so! I used them because from what little I understand of the PS/2-keyboard protocol from reading CCC’s introduction then a little additional research the key_ups are not optional and decided that leaving them out would violate CCC’s assumptions.
Ah, right. My apologies; I’d though that the idea of drawing log2(number of keys) bits of information per keypress already implied a rejection of the assumption that the PS/2 protocol would be used.
I was incidentally rather shocked at the way the protocol worked. 22 bits for a key_up? Why? That’s a terrible way to do it! (Charity suggests to me that bandwidth must not have been an efficient target of optimisation resources at the design time.)
Well, to be fair, the PS/2 protocol is only intended to be able to keep up with normal human typing speed. The bandwidth limit sits at over 80 characters per second, and I don’t think that anyone outside the realm of fiction is likely to ever type at that speed, even just mashing keys randomly.
Both is also a possibility (and from my re-analysis seems to be the most likely.)
Allow me to abandon inferences about interpretations and just respond to some words.
This claim is false. It would help a lot! It improves bandwidth by a factor of a little under two over not the alternative making optimal use of the key_up signal as well as the key_downs. As for how much improvement the keyboard change is over merely using all 10 fingers optimally… the math gets complicated and is dependent on things like finger length.
I agree. If just abandoning key_up scancodes altogether is permitted then obviously do so! I used them because from what little I understand of the PS/2-keyboard protocol from reading CCC’s introduction then a little additional research the key_ups are not optional and decided that leaving them out would violate CCC’s assumptions. I was incidentally rather shocked at the way the protocol worked. 22 bits for a key_up? Why? That’s a terrible way to do it! (Charity suggests to me that bandwidth must not have been an efficient target of optimisation resources at the design time.)
Yes, you are right. On re-reading and looking over this again, I see that misread you there; for some reason (even after I knew that misreading was likely) I read that as 2log2(number of keys) bits of information per keypress* instead of per 33 bits of information.
Ah, right. My apologies; I’d though that the idea of drawing log2(number of keys) bits of information per keypress already implied a rejection of the assumption that the PS/2 protocol would be used.
Well, to be fair, the PS/2 protocol is only intended to be able to keep up with normal human typing speed. The bandwidth limit sits at over 80 characters per second, and I don’t think that anyone outside the realm of fiction is likely to ever type at that speed, even just mashing keys randomly.
.
Characters per second and words per minute don’t match; wpm is typically calculated with 5 characters per word, so 80 cps would correspond to 960 wpm.