[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] QEMU bug with IRQ1 (keyboard) under DOS
From: |
Konstantin Koll |
Subject: |
[Qemu-devel] QEMU bug with IRQ1 (keyboard) under DOS |
Date: |
Fri, 29 Aug 2008 10:36:08 +0200 |
Dear QEMU team,
I have stumbled upon a bug in QEMU regarding the keyboard interrupt
handler. QEMU has got a bug regarding extended keyboard scan codes,
the BIOS, and the PS/2 protocol. The bug becomes apparent under DOS
and its assorted applications, since more sophisticated operating
systems do not rely on the BIOS to handle key strokes.
For a standard key, an IRQ handler for IRQ1 (INT9) will receive the
follwoing byte sequence (break = make + 80h):
Port 60h (data): m b
For an extended key, say 'arrow right', the sequence is:
Port 60h (data): m m b b
Now the IRQ handler receives 2 make codes for that key, invoking the
BIOS twice for that keystroke. However, the correct sequence should be:
Port 60h (data): = 0Eh m 0Eh b
Interestingly, Port 64h (status) behaves erratic, too. Bit 0 should
be set for any new key strokes in port 60h, and should automatically
revert to 0 by reading port 60h. For standard keys, Port 64h always
returns 1Ch. For extended keys, the sequence is 1Ch, 1Dh, 1Ch, 1Dh.
Only invoking the BIOS for 1Ch is a feasible workaround on first
sight. However, chaining multiple IRQ1 handlers becomes impossible,
as the status byte is changed on the first access to port 60h.
I am not currently subscribed to the mailing list.
Sincerely,
Konstantin Koll
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] QEMU bug with IRQ1 (keyboard) under DOS,
Konstantin Koll <=