PS/2 IRQ not firing + spurious IRQ (real hardware)

[Magyar57]

Hello,

I am testing my PS/2 driver on different platforms:
- On qemu, it works perfectly (both mouse & keyboard)
- On my desktop + actual PS/2 keyboard, works perfectly. I don't have a mouse to test though
- On my desktop + nothing plugged in, I get a 0xfc INSTEAD of an ACK on the self-test command (so I guess PS/2 emulation is not supported on my motherboard ?). Same for the mouse
- On a fairly old laptop (~2015), it works (both m&k)
- On a recent laptop (Lenovo Legion Slim 5), the initialization works, and there seems to be an emulated keyboard since it answers to commands. But IRQ 1 never gets fired when I press keys. When polling the keyboard, there is no data in the buffer (?). Moreover, a spurious IRQ 7 is raised when I try to set the keyboard's LEDs.

On my Lenovo laptop, why is there this spurious IRQ 7 ? Why is there no IRQ 1 fired / no data in the buffer ?

And another thing that I noticed: on both laptops, when identifying the keyboard, I get bytes 0xab, 0x41 as an answer even though translation is DISABLED. Is it a known hardware quirk, or is this a bug of mine ? Should I just accept the translated code ?

Here's my code: https://github.com/Magyar57/mugOS/blob/ ... vers/PS2.c
I am using the old PIC to handle interrupts, and the i8042 PS/2 controller

Thank you !

[Octocontrabass]

so I guess PS/2 emulation is not supported on my motherboard ?

Check the BIOS for a "legacy USB support" setting.

On my Lenovo laptop, why is there this spurious IRQ 7 ? Why is there no IRQ 1 fired / no data in the buffer ?

You're using a mix of polling and IRQs, and some piece of hardware or firmware doesn't like that. The PS/2 controller raises an IRQ whenever the output buffer is full, so you should only use polling before you enable IRQs in the configuration byte.

And another thing that I noticed: on both laptops, when identifying the keyboard, I get bytes 0xab, 0x41 as an answer even though translation is DISABLED. Is it a known hardware quirk, or is this a bug of mine ? Should I just accept the translated code ?

There are a lot of hardware quirks surrounding translation. You should leave translation enabled. (Unless the PC boots with translation disabled; then you should leave translation disabled.)

[Magyar57]

First, thanks for your time

so I guess PS/2 emulation is not supported on my motherboard ?

Check the BIOS for a "legacy USB support" setting.

I forgot about that, thank you. Unluckily, there is one and it was on already. So that's another bug I have then... Any idea why the emulated keyboard would not response any ACKs ?

On my Lenovo laptop, why is there this spurious IRQ 7 ? Why is there no IRQ 1 fired / no data in the buffer ?

You're using a mix of polling and IRQs, and some piece of hardware or firmware doesn't like that. The PS/2 controller raises an IRQ whenever the output buffer is full, so you should only use polling before you enable IRQs in the configuration byte.

I added polling as a debug check, it is not actually committed. And the behaviour is the same with or without the polling. My "actual" (none debug" code) never polls the device, and only uses IRQs (which aren't raised on this laptop)

And another thing that I noticed: on both laptops, when identifying the keyboard, I get bytes 0xab, 0x41 as an answer even though translation is DISABLED. Is it a known hardware quirk, or is this a bug of mine ? Should I just accept the translated code ?

There are a lot of hardware quirks surrounding translation. You should leave translation enabled. (Unless the PC boots with translation disabled; then you should leave translation disabled.)

Interesting. So do you advise supporting both translated and untranslated scancodes sets ? Afaik, Windows only supports one (the set 1 iirc), I don't know what Linux does.

I'll try implementing support for the default translation the keyboard is in. But I'm doubtfull it will fix the two bugs mentioned above

[Magyar57]

I can confirm that both using the default translation, and using scancode set 1 don't fix my issues

[Octocontrabass]

Any idea why the emulated keyboard would not response any ACKs ?

It might just be a bug in the emulation. Not much you can do about that until you have USB drivers.

My "actual" (none debug" code) never polls the device, and only uses IRQs (which aren't raised on this laptop)

You poll the PS/2 controller every time you send data to the keyboard or mouse. By the time you're communicating with devices attached to the PS/2 controller, the PS/2 controller itself should be fully initialized, and you should be using IRQs to receive any responses.

I'm certain this is the problem when you set the keyboard LEDs because a spurious IRQ7 occurs. I'm not sure why you don't receive IRQ1 the rest of the time, but it might be the same problem.

Interesting. So do you advise supporting both translated and untranslated scancodes sets ? Afaik, Windows only supports one (the set 1 iirc), I don't know what Linux does.

Linux supports translated and untranslated set 2, according to however the BIOS initialized the PS/2 controller. Windows supports translated set 2, but I'm not entirely sure what it will do if translation isn't enabled by the BIOS. An old document from Microsoft says Windows NT will enable translation, but there might be some (ancient) PCs where (ancient) Windows would use untranslated set 1 instead of trying to enable translation.

[Magyar57]

You poll the PS/2 controller every time you send data to the keyboard or mouse. By the time you're communicating with devices attached to the PS/2 controller, the PS/2 controller itself should be fully initialized, and you should be using IRQs to receive any responses.

I'm certain this is the problem when you set the keyboard LEDs because a spurious IRQ7 occurs. I'm not sure why you don't receive IRQ1 the rest of the time, but it might be the same problem.

Oh so you mean that I should be using IRQs to receive responses to commands from the devices ?
I read the linux kernel code for PS/2 keyboard initialization (mainly drivers/input/keyboard/atkbd.c which calls drivers/input/serio/libps2.c), and it seems to be using polling.

Additionally, I commented the code that sets the LEDs, spurious IRQ7 doesn't occur, but IRQ1 is still not raised... I'm really out of ideas for a fix

[Octocontrabass]

Oh so you mean that I should be using IRQs to receive responses to commands from the devices ?

Correct.

I read the linux kernel code for PS/2 keyboard initialization (mainly drivers/input/keyboard/atkbd.c which calls drivers/input/serio/libps2.c), and it seems to be using polling.

Where do you see polling? It looks like it's using interrupts to me.

Additionally, I commented the code that sets the LEDs, spurious IRQ7 doesn't occur, but IRQ1 is still not raised... I'm really out of ideas for a fix

Have you tried sending the command to set the LEDs but waiting for IRQ1 for the keyboard to acknowledge it instead of polling? Maybe the keyboard thinks you don't want it to send scan codes.

[pross]

I experienced similar "IRQ1 not firing" problem with new Lenovo laptop: viewtopic.php?t=57574

My solution was to use APIC instead of classic PIC, and process the interrupt source override entry for IRQ1.

[Magyar57]

I experienced similar "IRQ1 not firing" problem with new Lenovo laptop: viewtopic.php?t=57574
My solution was to use APIC instead of classic PIC, and process the interrupt source override entry for IRQ1.

Indeed, I saw your post before posting mine. But since you're getting scancodes when polling and I'm not, I'm suspecting it's not JUST an IRQ not firing. Or maybe it is because we have different laptops. I have plans to implement APIC support, but I guess it will be a long process, so I'd rather explore this possibility in last position, if that makes sense. But I'm pretty sure, whether or not it's the source of my problem right now, it will emerge later on. I'll keep you updated.

Have you tried sending the command to set the LEDs but waiting for IRQ1 for the keyboard to acknowledge it instead of polling? Maybe the keyboard thinks you don't want it to send scan codes.

I'm currently trying to figure out IRQ for commands responses. It is only for responses, right ? Tell me if I'm wrong, but when sending a command, our only solution is to poll the controller status register to see if the device is ready to accept a command (unlike the serial port which fires an IRQ when its buffer has room)

What do you mean "Maybe the keyboard thinks you don't want it to send scan codes", that scanning is disabled ? I activate it at the end of the initialization, along with irqs

[Octocontrabass]

I'm currently trying to figure out IRQ for commands responses. It is only for responses, right ? Tell me if I'm wrong, but when sending a command, our only solution is to poll the controller status register to see if the device is ready to accept a command (unlike the serial port which fires an IRQ when its buffer has room)

Yeah, the PS/2 controller only uses IRQs for receiving, not sending. Keep in mind the PS/2 controller doesn't know whether the byte is a response or a scan code; it's up to you to keep track.

What do you mean "Maybe the keyboard thinks you don't want it to send scan codes", that scanning is disabled ? I activate it at the end of the initialization, along with irqs

The firmware expects you to finish initializing the PS/2 controller, which includes enabling IRQs, before you start initializing the keyboard. Doing things in a different order might confuse the firmware.

[Magyar57]

The firmware expects you to finish initializing the PS/2 controller, which includes enabling IRQs, before you start initializing the keyboard. Doing things in a different order might confuse the firmware.

So you're telling me I should, in order:
- Disable devices interrupts
- Initialize the PS/2 controller
- Enable interrupts for both devices
- Initialize the devices (using interrupts)
right ?

The issue is, on my Lenovo laptop, when I send the initial command to read the controller configuration byte (in order to clear interrupts bits and write it back to the controller), i get an irq 1 (and then a spurious irq 7 ??). Additionally, If I try to read the byte in the irq handler, the status register indicates that there is nothing to be read in the data port...

To test, I tried not reading the control byte and guessing its initial value (setting the guessed value, with irq disabled) ; it worked in the sens that the irq doesn't fire anymore, but the keyboard self-test fails later on. And I need to know the default value of the translation, too, so I need to read the config byte.

[Octocontrabass]

The issue is, on my Lenovo laptop, when I send the initial command to read the controller configuration byte (in order to clear interrupts bits and write it back to the controller), i get an irq 1

That's the normal unhelpful behavior of the PS/2 controller. If the PS/2 controller has a response to a command you send to it, the response will arrive exactly the same way data from the keyboard arrives. You should mask IRQ1 in the interrupt controller to prevent unwanted IRQs before you're done with initialization.

(and then a spurious irq 7 ??). Additionally, If I try to read the byte in the irq handler, the status register indicates that there is nothing to be read in the data port...

You're reading the data port before the IRQ arrives (which is possible, since it has to go through the slow legacy interrupt controllers) or the PS/2 controller is not 100% IBM-compatible (which is also possible, because nobody cares as long as Windows runs). Maybe both.

[Magyar57]

You should mask IRQ1 in the interrupt controller to prevent unwanted IRQs before you're done with initialization.

Should I mask SPECIFICALLY irq 1 ?

I'm sorry, I got things confused last time.
What happens is:
- I mask interrupts (cli)
- I initialize the i8042 controller
- [optionally: wait 2s]
- Set interrupts (sti)
- Right away, irq 1 fires ; there's no data to be read, because I read it by polling during the initialization already
- Right away again, spurious irq 7 fires
- I then proceed to initialize the PS/2 keyboard (using irqs), which fails: irq don't fire anymore. (But I know there's a keyboard, because I could initialize it when I was using polling)

I'm guessing the late irq1 + spurious irq are what blocks later irqs to be fired, but I don't know how to verify nor fix this.
I feel that we're getting there though ! Do you think APIC could be my saviour ?

Additional unrelated question, but my other (old) laptop, when i set the LEDs, it ACKs twice. In qemu, I only get one ACK ; is this normal ? (maybe it ACKs the set led command, then the led value)

[Octocontrabass]

Should I mask SPECIFICALLY irq 1 ?

Yes.

Do you think APIC could be my saviour ?

Maybe, maybe not. Modern OSes only use APIC, so you're less likely to run into hardware or firmware bugs if you also use APIC, but it won't help if the bugs are in your code.

Additional unrelated question, but my other (old) laptop, when i set the LEDs, it ACKs twice. In qemu, I only get one ACK ; is this normal ? (maybe it ACKs the set led command, then the led value)

That's normal, you're supposed to wait for the keyboard to acknowledge each byte in case there's a transmission error.

[Magyar57]

Should I mask SPECIFICALLY irq 1 ?

Yes.

Well, that didn't change anything...
I'm properly stuck now. Guess I'll implement APIC support

That's normal, you're supposed to wait for the keyboard to acknowledge each byte in case there's a transmission error.

Indeed, I was messing up things by using the wrong function lol, thanks