qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] QEMU bug with IRQ1 (keyboard) under DOS
@ 2008-08-29  8:36 Konstantin Koll
  0 siblings, 0 replies; only message in thread
From: Konstantin Koll @ 2008-08-29  8:36 UTC (permalink / raw)
  To: qemu-devel

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2008-08-29  8:36 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-29  8:36 [Qemu-devel] QEMU bug with IRQ1 (keyboard) under DOS Konstantin Koll

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).