Keyboard Mappings for QEMU

[sbrookes]

Hi All,

I am one of the original authors of BearOS -- published open source here: https://github.com/SCSLaboratory/BearOS

The project has been dead for a few years but I am trying to breathe new life into it. First up will come a blog post on how I managed to get it to boot in qemu...

In the meantime, although I managed to get the kernel booting in qemu my keyboard mappings are screwed up. When I press the '3' key on my keyboard in the qemu console my OS receives a 't'. '8' is 'enter', 'd' is '1', etc. It is not quite random... pressing "1234" sends "erty", but then '5' sends to 'i'.

Twice per key press (regardless of what key is pressed), qemu spits out:

Code: Select all

qemu: unsupported keyboard cmd=0x9c
qemu: unsupported keyboard cmd=0x1c
qemu: unsupported keyboard cmd=0x9c
qemu: unsupported keyboard cmd=0x1c

So that is 8 lines printed per key press... 4 on press and 4 on release.

My qemu invocation:

Code: Select all

qemu-system-x86_64 -cpu host -accel kvm -netdev user,id=net0,net=192.168.88.0/24,tftp=/tftpboot/,bootfile=pxelinux.0 -device virtio-net-pci,netdev=net0 -serial stdio -m 4096 -smp 8

I am running qemu on a linux box but typing on my Mac (ssh'd into linux with X11 forwarding).

My google-fu wasn't strong enough to turn anything up, so any thoughts would be greatly appreciated! Thanks!

[Octocontrabass]

Whoever wrote the keyboard driver mixed up PC and AT documentation. Reading the byte from the AT (or PS/2) keyboard controller already acknowledges receipt, you don't need to strobe anything. Even if you wanted your driver to be compatible with the PC for some reason, you're strobing the wrong port, which is confusing the keyboard controller.

[sbrookes]

Whoever wrote the keyboard driver mixed up PC and AT documentation. Reading the byte from the AT (or PS/2) keyboard controller already acknowledges receipt, you don't need to strobe anything. Even if you wanted your driver to be compatible with the PC for some reason, you're strobing the wrong port, which is confusing the keyboard controller.

Wow! Thanks so much for taking the time to look through the code and find a mistake. I really appreciate it.

Commenting out the strobe didn't change much of anything except that I'm getting fewer "unsupported keyboard cmd" messages from qemu. Could you point me to some of the documentation you mentioned? I'm not sure what you mean by PC/AT here?

I'm surprised that this problem never cropped up on real hardware or VMWare where we ran the code in the old days...

Thanks!

[Octocontrabass]

Commenting out the strobe didn't change much of anything except that I'm getting fewer "unsupported keyboard cmd" messages from qemu.

If you're still seeing those, something is still wrong.

Could you point me to some of the documentation you mentioned? I'm not sure what you mean by PC/AT here?

By "PC" I mean the original IBM PC. "AT" refers to the first fully 16-bit successor. You can find the official IBM manuals here, but you should also use other references (like the wiki) since those old manuals won't tell you anything about newer hardware.

I'm surprised that this problem never cropped up on real hardware or VMWare where we ran the code in the old days...

Maybe you were just lucky? Maybe X11 forwarding doesn't play nice with QEMU and you should try VNC instead?

[sbrookes]

It turns out it was an x11 problem after all. I missed a critical warning at the beginning of the output which led me to this thread https://qemu-devel.nongnu.narkive.com/A ... n-keycodes

Updating qemu solved the problem!

Glad I posted here though because it helped me find other bugs in the keyboard implementation.

Thanks so much!!

[austanss]

aye thats what we here for