Re: [Qemu-devel] Regression: more 0.12 regression (SeaBIOS related?)

[Roy Tam <roytam@gmail.com>]

2010/3/11 Kevin O'Connor <kevin@koconnor.net>:
> On Wed, Mar 10, 2010 at 01:24:27PM +0800, Roy Tam wrote:
>> 2010/3/10 Kevin O'Connor <kevin@koconnor.net>:
>> > I don't see an "Illegal Instruction" message.  Instead, I see the
>> > keyboard just not working.  What qemu version and what command line
>> > did you use?
>>
>> latest git today. when you type fast.
>
> Bleh.  That image defines an int15 wrapper which corrupts %edi.
> SeaBIOS calls int154f from the keyboard irq, and it is not prepared to
> handle a corrupted edi.  In contrast, Bochs BIOS doesn't care if the
> registers change.
>
>> > What the fdos0138.img image is doing is broken - once it reads the key
>> > from the ps2 port, nothing stops a new key from being read the next
>> > time something reads from the port.  Indeed, although the keyboard
>> > works in qemu-0.11 for fdos0138.img, if one types fast they'll see
>> > duplicate and lost keys.
>> >
>>
>> But it is how programs(Chinese/Japanese/Korean Display Systems,
>> GW-BASIC, etc.) in the past get input from keyboard.
>
> Can you point me to documentation on this usage?
>

Sorry I can't find documentation on this usage. But instead I have
lots of old programs written with this usage.
Using undocumented features from BIOS/DOS is very usual in that time.

>> "Consider" legacy as "broken" is wrong IMHO.
>
> It's broken because it causes key presses to be lost and corrupted.
> The ps2 port hardware just doesn't work the way that software is
> trying to use it.
>

You said that "it causes key presses to be lost and corrupted" but I
haven't heard any complain about this.
Real BIOSes (Award BIOS, AMI BIOS, Phoenix BIOS) handle this usage
very well and no key press are lost or corrupted.
Any key press should generate 4 IRQs, for example when I press [Tab]
key, it should have IRQs like this:
ps2: data f (status=1d)
ps2: data f (status=1c)
ps2: data 8f (status=1d)
ps2: data 8f (status=1c)

Even if status&1==1 is handled by the program itself, status==0x1c is
still handled by BIOS.
Programs in the past will try to get data from BIOS in this moment to
ensure two scancodes are the same.

On the contrary *NOT* sending keycode in this moment cause bigger problem.

The following patch help people to see irq status and data change:
---
diff --git a/src/ps2port.c b/src/ps2port.c
index 49bf551..48d940f 100644
--- a/src/ps2port.c
+++ b/src/ps2port.c
@@ -154,11 +154,19 @@ process_ps2byte(u8 status, u8 data)
 static void
 process_ps2bytes(void)
 {
+    u8 status = 0;
+    u8 data = 0;
+    u8 old_status = 0;
+    u8 old_data = 0;
     for (;;) {
-        u8 status = inb(PORT_PS2_STATUS);
+        old_status = status;
+        old_data = data;
+        status = inb(PORT_PS2_STATUS);
+        data = inb(PORT_PS2_DATA);
+        if ((data != old_data)||(status!=old_status))
+            dprintf(1, "ps2: data %x (status=%x)\n", data, status);
         if (!(status & I8042_STR_OBF))
             return;
-        u8 data = inb(PORT_PS2_DATA);
         process_ps2byte(status, data);
     }
 }