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

[Natalia Portillo]

El 11/03/2010, a las 07:42, Roy Tam escribió:

> 2010/3/11 Kevin O'Connor <address@hidden>:
> > On Wed, Mar 10, 2010 at 01:24:27PM +0800, Roy Tam wrote:
> > > 2010/3/10 Kevin O'Connor <address@hidden>:
> > > > 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.

I cannot check it out right now but I remember to have read that this  
is the usual behaviour, not for Asian display systems (that use  
combinational character recognition in software (pressing K and A with  
a japanese IME writes the KA kana), but for modifiers (CTRL, ALT, so  
on).

If you just press A the scancode is just A, then nothing (two reads).
If you press CTRL-A, the scancode is CTRL, then A (two reads).

Anyway this can be tested in real hardware easily. Norton Utilities  
diagnostics shown the scancodes.

> > > "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);
>     }
> }