2010/3/12 Kevin O'Connor kevin@koconnor.net:
On Thu, Mar 11, 2010 at 03:42:28PM +0800, Roy Tam wrote:
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.
Can you confirm these other programs fail in the same way (no keyboard input, and "ps2 irq but no data." messages in log when using bios.bin-0.5.1-debug-20100228)?
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.
Under qemu-0.11 normal typing lead to lots of keyboard errors for me. It's possible real hardware would be less susceptible to this error, but there is nothing that a BIOS inside qemu can do to stop the corruption.
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)
There is one irq on key press and one irq on key release. Your debugging output is in a loop and you're reporting the same event twice.
The following patch help people to see irq status and data change:
The current SeaBIOS flow is effectively:
// Read ps2 port status u8 status = inb(PORT_PS2_STATUS); if (!(status & I8042_STR_OBF)) // No event in queue - nothing can be dequeued. return; // Event in queue - dequeue it u8 data = inb(PORT_PS2_DATA); // Process the event. process_ps2byte(status, data);Your debugging patch is not correct becuase it performs the event dequeue before the check to see if there is an event in the queue.
I don't care about it. As mentioned in OSDEV wiki ( http://wiki.osdev.org/PS2_Keyboard ): Note that if you repeatedly read the port 0x60 without waiting for another IRQ, you'll read the same byte again. That's the 'normal' behaviour of keyboard controller, [...]