OSDev.org

Octocontrabass wrote:But commands are also handled by the keyboard driver, aren't they?

Well, yes. At this stage everything is driven by keyboard's ISR. Commands could be addressed to controller too.
I guess I need to check if there's an active command in queue and if the received byte is one of the 0,0xfe,0xff then it's reply to a request.

Well, it turns out qemu is able to send scancode even if command is in progress. For example: I was trying to set numlock state. I send command 0xed, wait for 0xfa. Once it's confirmed I assume command is in progress and hence any answer from encoder is command related. qemu has no problem sending 0xf0 during this time as part of the numlock break code.

The accuracy of QEMU's PS/2 emulation is questionable at best. Fortunately, there are only two possible responses to command 0xED, so you can safely assume any values other than 0xFA or 0xFE are part of a scan code.

It sounds like you've turned off translation as well. That's fine in QEMU, but on real hardware it can prevent laptop Fn keys from working correctly, and SMM PS/2 emulation may not allow translation to be turned off.

I see this will be fun. I wanted to avoid sorting/matching scancode in ISR for all possible options, it seems I might do that after all.

Octocontrabass wrote:It sounds like you've turned off translation as well.

Yes, I did. Scancode1 seems easier to handle as I can usually distinguish break code for a given key in one byte. Many articles (including wiki) suggest to disable translation. I've no personal preference on this as I don't have experience doing either. As my test HW didn't show any issues with it I went with it. Do you recommend to actually keep it enabled ? (given the issues you mentioned)

mtbro wrote:I wanted to avoid sorting/matching scancode in ISR for all possible options, it seems I might do that after all.

I don't see why you would need to sort anything in your ISR. Put them in a buffer and your keyboard driver can figure out what to do with them. Your keyboard driver should know when it's expecting a reply from a command since your keyboard driver sent the commands, right?

mtbro wrote:Do you recommend to actually keep it enabled ? (given the issues you mentioned)

If you want your OS to work correctly on other people's hardware, yes. If you don't care whether other people can make your OS run, then do whatever you like.

Octocontrabass wrote:I don't see why you would need to sort anything in your ISR. Put them in a buffer and your keyboard driver can figure out what to do with them

Right now my ISR is pretty much part of the keyboard driver. At this early stage the only way to trigger anything driver related is via interrupt, hence ISR. I do put them into buffer (I'm attempting to sort them as command replies and the rest as part of command debugging).
In the future I plan to have ISR update the buffer and notify driver it has new data. This would be handled by a driver task that would get scheduled. But I'm nowhere near that plan yet.

Octocontrabass wrote:If you want your OS to work correctly on other people's hardware, yes.

Translation on it is then.

My dev VM is running qemu 5.2.0. It seems this is fixed on higher versions of qemu (tested on 6.x). But I guess I still need to reconsider how I handle things.