From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MfL2j-0007Do-K0 for qemu-devel@nongnu.org; Sun, 23 Aug 2009 17:56:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MfL2g-00078Y-27 for qemu-devel@nongnu.org; Sun, 23 Aug 2009 17:56:05 -0400 Received: from [199.232.76.173] (port=54353 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfL2f-00078U-Ra for qemu-devel@nongnu.org; Sun, 23 Aug 2009 17:56:01 -0400 Received: from mail2.shareable.org ([80.68.89.115]:41350) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MfL2f-0004XW-Cn for qemu-devel@nongnu.org; Sun, 23 Aug 2009 17:56:01 -0400 Date: Sun, 23 Aug 2009 22:55:58 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 0 of 1] Fix for DOS keyboard problems Message-ID: <20090823215558.GA9093@shareable.org> References: <20090823124410.GA30789@shareable.org> <53e878390908231020s32575288jf2dd1450bae241c9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53e878390908231020s32575288jf2dd1450bae241c9@mail.gmail.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Ring Cc: qemu-devel@nongnu.org Stefan Ring wrote: > The particular problem that I noticed and that is 100% reproducible > and also very understandable when you look at what the DOS programs > do, is that in Borland's Text-Mode DOS IDEs (most likely BC++ 3.1, 4, > Turbo Pascal 6 but definitely Turbo Pascal 7) and IIRC also in Turbo > Vision programs generated by them, every cursor key press is > interpreted twice. So when you open up the leftmost menu and press the > down cursor key once, the third entry gets selected instead of the > second one. > > The reason for this is that said programs install an IRQ 1 handler > which does little more than read from port 60h and pass control to the > underlying BIOS (or keyboard driver) handler. The BIOS handler reads > port 60h again, and should apparently see the same value as the first > handler. The problem with the cursor keys is that they generate two > scan codes in succession on port 60h that should be read by two > separate IRQ handler activations but because QEMU's original behavior > is to consume one data byte per read from 60h, the data gets used up > too fast. Let's see if I understand your explanation. 1. Cursor key is pressed. The key press is represented as two scan codes. 2. IRQ 1 is entered. 3. Borland's code reads port 60h - gets the first scan code. 4. BIOS's code reads port 60h - gets the second scan code. 5. Return from IRQ 1. 6. Cursor key is released. The key release is represented as two scan codes. 7. IRQ 1 is entered. 8. Borland's code reads port 60h - gets the first scan code. 9. BIOS's code reads port 60h - gets the second scan code. 10. Return from IRQ 1. So both Borland's code and the BIOS are *missing* scan codes. How does that result in Borland seeing *multiple* cursor key press/release sequences? Apparently when port 0x60 is read, that de-asserts IRQ1, resets the IBF flag ("input buffer full"), and another byte could be received from the keyboard. However, reading port 0x60 quickly, before another byte can be received over the keyboard cable, should return the same byte. So I agree that the emulated port 0x60 should return the same value if there has not been enough time for the (emulated) keyboard cable to transmit another scan code. But detecting the particular sequence used by Borland code and the BIOS together is a hack. I'm not surprised that, as you say, other DOS keyboard drivers remain broken after the patch. If it goes in, the patch should include a very clear comment that the "held" value and detecting the disable/read/enable sequence is only a workaround for what Borland does and also depends on the BIOS sequence, and is not a correct emulation in general. -- Jamie