qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0 of 1] Fix for DOS keyboard problems


From: Stefan Ring
Subject: Re: [Qemu-devel] [PATCH 0 of 1] Fix for DOS keyboard problems
Date: Mon, 24 Aug 2009 00:54:22 +0200

On Sun, Aug 23, 2009 at 11:55 PM, Jamie Lokier<address@hidden> wrote:
> 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?

Actually I wondered about the same thing while I wrote my previous
answer... I'm not exactly sure, but it seems to happen like this: the
cursor keys generate two scan codes - E0h and the real scan code in
this order. Somehow the second IRQ seems to happen although its value
has already been consumed by the first interrupt handler activation,
and during the second invocation the handler will just get repetitions
of the last value read. Apparently the scan code for the cursor keys
is interpreted as cursor movement regardless if E0h appeared earlier
or not.

Another symptom is that when typing text inside Turbo Pascal, about
1/3 - 1/4 of the characters typed are doubled randomly.

> But detecting the particular sequence used by Borland code and the
> BIOS together is a hack.

Yes, it is a hack. But it's not only Borland - there are some reports
about some other software in various places as well. The VirtualBox
cases [1] and [2] mention some more, and then there is a post in a
german discussion board[3] (the linked post is written in english)
about this strange "OS"[4]. The german one is interesting, although
I'm not sure if his observations are correct. There is another one a
few posts further down which states that the problem had already been
discussed on the FreeDOS mailing list and is known to "the QEMU
developers". Well, it must have been known to Fabrice Bellard when he
first created it.

> I'm not surprised that, as you say, other
> DOS keyboard drivers remain broken after the patch.

Apparently, DOS keyboard drivers don't normally lock and unlock the
keyboard like the Bochs BIOS does.

> 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.

I agree, and there's already an "XXX" in that file stating that there
should be a timer[5], although I don't completely understand that
comment - I don't see how that would help because this function gets
called every time the keyboard is re-enabled by the BIOS handler.
Bochs does the timer thing correctly. I don't know how complicated it
would be to add the timer to QEMU, but I expect it would have been
done already if it were easy.The hack at least improves matters a bit.

[1] http://www.virtualbox.org/ticket/58
[2] http://www.virtualbox.org/ticket/1599
[3] http://dwforum.wcx-network.com/viewtopic.php?p=2266#2266
[4] http://www.deskwork.de/FOTOS/
[5] 
http://git.savannah.gnu.org/cgit/qemu.git/tree/hw/pckbd.c?id=2a1704a71d851624175509a2b15a000dcc7c0386#n132




reply via email to

[Prev in Thread] Current Thread [Next in Thread]