I was reading this QA ( How was the clock frequency of the PS/2 keyboard protocol chosen? ) and read in the replies that a high frequency was chosen (at least in-part) to reduce the latency between a keypress and the computer receiving the event.

I wondered what if a keyboard interface was designed using a clockless parallel-port interface to the computer (by "parallel-port" I mean any cable or connection using parallel data-lines, not just a PC parallel printer port), for example, using 8 data conductors to represent a 7-bit scancode and a 1-bit Pressed/Not-pressed state bit - and each change in the data-lines would be triggered immediately any change in physical keyboard state, and this could hypothetically be done using entirely analog circuity: no need for clock signal, polling, and this means it would also support unlimited N-key rollover.

The host-device would be responsible for tracking key-press state, but it would only need 127 hardware bits and then raise the CPU/OS keyboard interrupt when a keyboard state-change is sensed on the port's lines.

(This approach wouldn't preclude port multiplexing either: just add additional bits to represent a device-ID).

I did a quick-search online for "parallel-port keyboard" and "scsi port keyboard" but I didn't find anything relevant.

Somewhat related: my primary-school in the UK had BBC Micros, and some of them had concept-keyboards attached to them (probably this exact model, actually - I remember it having a blue casing and a ribbon cable attaching it to the computer - so I suppose that's one example, but it's not a "true" keyboard (AFAIK while the "user port" was a parallel port, it did require polling by software instead of being capable of raising hardware keyboard interrupts).

I was reading this QA ( How was the clock frequency of the PS/2 keyboard protocol chosen? ) and read in the replies that a high frequency was chosen (at least in-part) to reduce the latency between a keypress and the computer receiving the event.

I wondered what if a keyboard interface was designed using a clock-less parallel port interface to the computer (by "parallel port", I mean any cable or connection using parallel data lines, not just a PC parallel printer port).

For example, one using 8 data conductors to represent a 7-bit scan code and a 1-bit Pressed/Not-pressed state bit. Each change in the data lines would be triggered immediately on any change in physical keyboard state. This could hypothetically be done entirely with analog circuity, so no need for clock signal or polling. This means it would also support unlimited N-key rollover.

The host-device would be responsible for tracking keypress state, but it would only need 127 hardware bits. It would raise the CPU/OS keyboard interrupt when a keyboard state-change was sensed on the port's lines.

(This approach wouldn't preclude port multiplexing either. Just add additional bits to represent a device-ID).

I did a quick-search online for "parallel port keyboard" and "scsi port keyboard" but I didn't find anything relevant.

Somewhat related: my primary-school in the UK had BBC Micros and some of them had concept-keyboards attached to them (probably this exact model, actually). I remember it having a blue casing and a ribbon cable attaching it to the computer. So I suppose that's one example but it's not a "true" keyboard.

AFAIK, while the "user port" was a parallel port, it did require polling by software instead of being capable of raising hardware keyboard interrupts.

I was reading this QA ( How was the clock frequency of the PS/2 keyboard protocol chosen? ) and read in the replies that a high frequency was chosen (at least in-part) to reduce the latency between a keypress and the computer receiving the event.

I wondered what if a keyboard interface was designed using a clockless parallel-port interface to the computer (by "parallel-port" I mean any cable or connection using parallel data-lines, not just a PC parallel printer port), such that 8 data conductors were used to represent a 7-bit scancode and a 1-bit Pressed/Not-pressed state bit - and each change in the data-lines would be triggered immediately any change in physical keyboard state, and this could hypothetically be done using entirely analog circuity: no need for clock signal, polling, and this means it would also support unlimited N-key rollover.

The host-device would be responsible for tracking key-press state, but it would only need 127 hardware bits and then raise the CPU/OS keyboard interrupt when a keyboard state-change is sensed on the port's lines.

(This approach wouldn't preclude port multiplexing either: just add additional bits to represent a device-ID).

I did a quick-search online for "parallel-port keyboard" and "scsi port keyboard" but I didn't find anything relevant.

Somewhat related: my primary-school in the UK had BBC Micros, and some of them had concept-keyboards attached to them (probably this exact model, actually - I remember it having a blue casing and a ribbon cable attaching it to the computer - so I suppose that's one example, but it's not a "true" keyboard (AFAIK while the "user port" was a parallel port, it did require polling by software instead of being capable of raising hardware keyboard interrupts).

I was reading this QA ( How was the clock frequency of the PS/2 keyboard protocol chosen? ) and read in the replies that a high frequency was chosen (at least in-part) to reduce the latency between a keypress and the computer receiving the event.

I wondered what if a keyboard interface was designed using a clockless parallel-port interface to the computer (by "parallel-port" I mean any cable or connection using parallel data-lines, not just a PC parallel printer port), for example, using 8 data conductors to represent a 7-bit scancode and a 1-bit Pressed/Not-pressed state bit - and each change in the data-lines would be triggered immediately any change in physical keyboard state, and this could hypothetically be done using entirely analog circuity: no need for clock signal, polling, and this means it would also support unlimited N-key rollover.

The host-device would be responsible for tracking key-press state, but it would only need 127 hardware bits and then raise the CPU/OS keyboard interrupt when a keyboard state-change is sensed on the port's lines.

(This approach wouldn't preclude port multiplexing either: just add additional bits to represent a device-ID).

I did a quick-search online for "parallel-port keyboard" and "scsi port keyboard" but I didn't find anything relevant.

Somewhat related: my primary-school in the UK had BBC Micros, and some of them had concept-keyboards attached to them (probably this exact model, actually - I remember it having a blue casing and a ribbon cable attaching it to the computer - so I suppose that's one example, but it's not a "true" keyboard (AFAIK while the "user port" was a parallel port, it did require polling by software instead of being capable of raising hardware keyboard interrupts).