PS/2 scan code set 2 issues
-
ThisIsAnEpicUsername
- Posts: 5
- Joined: Sun Dec 25, 2022 1:16 pm
PS/2 scan code set 2 issues
Im having an issue while trying to use scan code set 2 for my keyboard PS/2 driver. When i get an IRQ saying a key has been released, i get another IRQ after it saying it is pressed again even if it wasn't, so a key is always registered down after it has been pressed only once. This happens sometimes on real hardware, always on QEMU and never in Bochs. Is this an issue with my driver, or with PS/2 keyboard using scan code set 2?
-
Octocontrabass
- Member
- Posts: 5562
- Joined: Mon Mar 25, 2013 7:01 pm
Re: PS/2 scan code set 2 issues
That sounds like an issue with your driver. Have you tried logging the scan code bytes as you receive them? If you're receiving any extra scan code bytes, they'll appear in your log.
Re: PS/2 scan code set 2 issues
Hi,
If it wasn't for this quote...
For example, when you press 'S', you will get a single byte from the keyboard: 0x1B
When you release the 'S', you will get two bytes from the keyboard: 0xF0 and 0x1B
Are you mistakenly thinking that the 0x1B is a new 'make' code?
However, since you did say the above quote, I agree with Octocontrabass, I think it to be within your driver, and a log is a good suggestion.
Ben
- https://www.fysnet.net/osdesign_book_series.htm
If it wasn't for this quote...
...my question is that you do realize that a break code for set 2 is 0xF0 and then the key that is being released?ThisIsAnEpicUsername wrote:This happens sometimes on real hardware, always on QEMU and never in Bochs. Is this an issue with my driver, or with PS/2 keyboard using scan code set 2?
For example, when you press 'S', you will get a single byte from the keyboard: 0x1B
When you release the 'S', you will get two bytes from the keyboard: 0xF0 and 0x1B
Are you mistakenly thinking that the 0x1B is a new 'make' code?
However, since you did say the above quote, I agree with Octocontrabass, I think it to be within your driver, and a log is a good suggestion.
Ben
- https://www.fysnet.net/osdesign_book_series.htm
-
ThisIsAnEpicUsername
- Posts: 5
- Joined: Sun Dec 25, 2022 1:16 pm
Re: PS/2 scan code set 2 issues
Hello, thanks for the replies. I fixed the issue - I didn’t realise 2 interrupts were send, one for 0xF0 and another for the key byte. Instead, once I received the first interrupt I read both bytes, so when I received the second interrupt I got what appeared to be the make code and registered a key press. Thanks for the help, anyways.
Re: PS/2 scan code set 2 issues
Yes, as you found out, the keyboard will fire an interrupt when it has a byte ready to be read from the output buffer. If the current make/break code is two or more chars, it will interrupt once for each char.
It is up to the hardware (in this case, the emulator) on when to update the output buffer with the next char.
Since you were able to read both bytes on one interrupt notification, QEMU must update the output buffer with the next byte after a read from the port. Hence "always in QEMU". However, Bochs may only update the output buffer on an interrupt notification, hence the "never in Bochs".
The key here (no pun intended) is to remember that you must only read from the keyboard output buffer once per interrupt. Any additional read is considered undefined.
Also, please note that scan set 2 does have a few make/break codes that are multi-byte codes. Does your driver allow for multi-byte codes?
Ben
It is up to the hardware (in this case, the emulator) on when to update the output buffer with the next char.
Since you were able to read both bytes on one interrupt notification, QEMU must update the output buffer with the next byte after a read from the port. Hence "always in QEMU". However, Bochs may only update the output buffer on an interrupt notification, hence the "never in Bochs".
The key here (no pun intended) is to remember that you must only read from the keyboard output buffer once per interrupt. Any additional read is considered undefined.
Also, please note that scan set 2 does have a few make/break codes that are multi-byte codes. Does your driver allow for multi-byte codes?
Ben