The tool I use to see what scancodes a keyboard is actually returning is one I wrote: KB, running under DOS so it drives the hardware directly. This tends to avoid problems with operating systems being helpful and interpreting or throwing away scancodes; it also lets you see the keyboard ID and select any of the three scancode sets, translated or untranslated.
(Would it help if we referred to the left-hand 10 key positions as L1-L10, like on a Sun Type 3 keyboard?)
L1-L10 is not bad, but for new folks, nothing will be all that clear. c'est la vie.
I don't mess with translation, I read them via an atmel micro, either a teensy or atmega168 etc.. depending on what I have at hand. Also dodges the OS attacking the events. I don' have a machine handy that boots dos, and I needed to handle that code anyway, so I just pipe a debugging stream off of my project(s), via SPI to a serial converter, and thence to a log file. Considered the dos solution, though - remembered that there were commands to switch the mode of the keyboard, and of course, the bios interrupts to disable translation and get a headsup when there were new bytes.
I forget how the prefixes were handled, though - what do you get for stuff like the extended keys and the pause key when in mode 2? Do you get to see the whole string of bytes, or is the i8042 parsing that?
Anyway, it's definitely the sane way to approach figuring out the keystrokes. If I weren't so deep into my controller projects I would have tried much harder to find a way to do it in DOS.
OK, I'm off to edit up a post for the UB40T56, mode 2, no-jumper-3 table,
dfj