Octocontrabass wrote:
The BIOS assumes set 1 by default, since that's required for compatibility with DOS software (though not necessarily DOS itself). Whether the keyboard controller is translating from set 2/set 3 or providing untranslated set 1 directly from the keyboard is irrelevant to the BIOS.
This, I figured, since this was the whole reason for the translation to begin with.
Octocontrabass wrote:
Windows typically operates with translation enabled and the keyboard configured for set 2, which is effectively the same as set 1. Unfortunately, that's the default power-on state for most PCs, so I have no idea what Windows would do if the PC didn't boot in that configuration.
This is why this issue came up for me. I do not assume anything and check to see what set is being sent and if it is being translated.
Octocontrabass wrote:
Have you disabled USB legacy emulation? I'm sure you're much more familiar with USB than I am, but I figured I should ask just in case.
The problem is that I might need, and sometimes do need keyboard interaction before the USB is detected. For example, when booting from USB, of course you know that the USB is being emulated, but when booting from USB, then trying to detect which device/partition/etc I booted from, the emulated USB media is no longer available. Therefore, I ask the user to select from a displayed list, which needs keyboard interaction.
Octocontrabass wrote:
Do you continue to receive scan codes from set 1 even with translation enabled and the keyboard programmed for set 1? (On fully IBM-compatible hardware, this combination should result in nonsense scan codes.)
No difference. In fact, some of the key presses, no matter the keyboard's scan code setting, return additional break codes. For example, the right arrow returns the expected make code and the first two bytes are the expected break code, but appends another two-byte break code. This happens no matter what setting I am using. Both translated and untranslated, scan set 1, 2, or 3.
Octocontrabass wrote:
Does the laptop have a PS/2 port, or support for a dock that may include a PS/2 port? Multiplexing between PS/2 ports can be... challenging.
The laptop does not include an external PS/2 port. After more digging, and telling my OS to assume (uurrrggg) scan set 1, I was able to continue booting. I then was able to find out that the keyboard and pointer device pad (the little mouse moving device pad in front of the keyboard) are both either actual USB devices, a compound USB device, or emulated as USB devices. I'm leaning more as a compound device as a hub, with three ports (three?), one for keyboard, one for the pointing device, and an empty one, though no physical port is available.
Octocontrabass wrote:
What kind of laptop is it, anyway?
Dell Inspiron 1720 with an Intel ICH8 motherboard (H2801HB).
The specs for this MB state that:
"When a USB keyboard is plugged into the system, and a standard keyboard is not, the system may not boot, and MS-DOS legacy software will not run, because the keyboard will not be identified. The ICH8 implements a series of trapping operations which will snoop accesses that go to the keyboard controller, and put the expected data from the USB keyboard into the keyboard controller."
This tells me that there is an actual 8042 type keyboard controller, or at least the system "emulates" one. However, I don't like the "trapping operating".
The specs go on to say:
"The scheme described below assumes that the keyboard controller (8042 or equivalent) is on the LPC bus."
And finally:
"This legacy operation is performed through SMM space."
This tells me that I need to look into what the SMM is doing each time I press a key.
Anyway, thanks for the comments, I am still continuing to look for answers.
Ben
P.S. I forgot to mention, the Specs also state:
"The logic also needs to block the accesses to the 8042. If there is an external 8042, then this is simply accomplished by not activating the 8042 CS."
If all access to the 8042 is actually being blocked, this would explain what is happening, since my code to clear bit 6 of the Command Register never makes it to the physical controller, hence translation is always being done.