From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KYzSw-0006cJ-B2
	for qemu-devel@nongnu.org; Fri, 29 Aug 2008 04:36:22 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KYzSu-0006Yu-9u
	for qemu-devel@nongnu.org; Fri, 29 Aug 2008 04:36:21 -0400
Received: from [199.232.76.173] (port=42116 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KYzSu-0006Xa-4Z
	for qemu-devel@nongnu.org; Fri, 29 Aug 2008 04:36:20 -0400
Received: from mail.gmx.net ([213.165.64.20]:60647)
	by monty-python.gnu.org with smtp (Exim 4.60)
	(envelope-from <konstantinkoll@gmx.de>) id 1KYzSr-0001oG-Qs
	for qemu-devel@nongnu.org; Fri, 29 Aug 2008 04:36:18 -0400
Date: Fri, 29 Aug 2008 10:36:08 +0200
From: Konstantin Koll <konstantinkoll@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <E1KYzSu-0006Yu-9u@lists.gnu.org>
Subject: [Qemu-devel] QEMU bug with IRQ1 (keyboard) under DOS
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

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