ISO: Keyboard/mouse for MIPS RC2030 workstation
Maciej W. Rozycki
macro at linux-mips.org
Mon May 16 03:05:17 CDT 2016
On Sun, 15 May 2016, Josh Dersch wrote:
> And scratch what I said about the keyboard -- recalling that there are
> "standards" and then there are "standards" I grabbed a different AT keyboard
> from the shelf and tried it, just in case. And it works perfectly. So, it's
> a "standard" AT keyboard, but be careful which one you choose :).
There's the XT keyboard (83 keys), the AT keyboard (84 keys; same as XT
plus <SysReq>) and the PS/2 keyboard (originally 101/102 keys, but other
variants were later produced; this added the cursor pad, editing keys,
<F11>, <F12>, etc.). The XT and AT keyboards have a different fixed scan
code set each. For backwards compatibility with existing PC software the
i8042 microcontroller used on original PC/AT systems to interface the
keyboard translated AT scan codes on the fly to their XT equivalents;
there's little hassle here, because the key set is almost the same. This
translation can be disabled by software with a suitable command issued to
the i8042, to reveal the native scan code set.
With the PS/2 keyboard things turned different, the keyboard has 3 scan
code sets to choose from. Again for backwards compatibility, it powers up
in the AT scan code mode. Newly added keys are sent as multibyte codes
with a 0xe0 prefix, which legacy software can ignore and still yield
reasonable resultr; there are other quirks as well. Software can switch
the keyboard into one of the other 2 modes, either XT or native PS/2, with
a suitable command issued to the keyboard itself. For sensible results
translation in the i8042 has to be disabled as well if using these modes.
The XT mode is nothing fancy, again multibyte codes with a 0xe0 prefix
are used and the same quirks are present, except XT scan codes are
otherwise sent.
The native PS/2 mode on the other hand presents a uniform single-byte
scan code set across all keys, and the quirks are gone too. Unlike in the
other modes individual keys can have their press, release and typematic
events independently programmed. This is why some operating systems chose
to reprogram the keyboard to use this mode.
However, as usually, some hardware vendors did not feel compelled to
implement this feature set correctly in keyboard firmware, because all
they're cared was DOS/Windows compatibility and that software didn't
bother to fiddle with the keyboard. Consequently some supposedly
PS/2-compatible keyboards are hardwired to the AT mode. Worse yet, they
return the success code for scan code switch commands, and happily ignore
them, so flexible software can't figure out what's happening. And of
course some i8042 firmware implementers "forgot" to implement the
translation-disable command as well -- again with no means to detect the
situation.
So it looks to me like the first keyboard you've tried just suffers from
crippled firmware.
FWIW,
Maciej
More information about the cctalk
mailing list