Possibly buggy PS/2 keyboards when using scancode set 1?

[earlz]

Hi, I'm developing something that isn't an OS, per-se, but I figured I could get the most help here.

Basically, I have a small ARM processor that is accessing a PS/2 keyboard. I'm about 99% sure my driver for it is fully working and bug free. Now, I've experienced a very weird issue.

I copied my scancode-ASCII translation table from one of my old PC OS projects. This project assumed a scancode set of 1.

Modern keyboards appear to startup in scancode set 2 however. So, I did what I thought was reasonable and set my initialization code to set the scancode set to 1. It appears though that scancode set 1 only sorta works and is really buggy on every keyboard I've found so far. Basically, I'll mash keys and every so often my driver will actually receive a (correct) scancode. Typomatic repeat works flawlessly however.

Has anyone experienced this problem with PS/2 keyboards? I know that the PC keyboard controller by default does translation from scancode set 2 to 1, though the wikipedia page for scancodes appears to indicate that all keyboards should support sets 1 and 2.

Basically, before I go through the hassle of changing my translation table, has anyone else experienced this problem or have any ideas what could cause this?

My initialization code is very simple:

Code: Select all

char txdat[6] = "\xFF\xF5\xF0\x01\xF4";

That translates to: Reset, Set defaults and disable keyboard, Set scancode set 1, enable keyboard

[Brendan]

Hi,

I know that the PC keyboard controller by default does translation from scancode set 2 to 1, though the wikipedia page for scancodes appears to indicate that all keyboards should support sets 1 and 2.

It does? I read it carefully and couldn't find anything on that page (or recent older versions of that page) that says anything about the chance of different scancode sets being supported/not supported on modern keyboards.

Basically, I'll mash keys and every so often my driver will actually receive a (correct) scancode.

If some keys always work correctly and some keys never work correctly; then there's probably a dodgy translation happening. By comparing the scancode you get to the scancodes you should get, it may be possible to determine what is going wrong where. In this case the first thing I'd do is check if the keyboard is actually sending scancode set #2 (e.g. has it ignored your "set scancode set #1" command).

If the same key works sometimes and doesn't work other times, then it's very unlikely that the problem is caused by scan code sets or translation. In this case, given that key repeat works, it's unlikely to be a problem with serial communications (baud rate, parity, etc). That doesn't leave many other causes.


Cheers,

Brendan

[earlz]

Ah, I guess I didn't read that it'd be compatible.

Anyway, from my testing it appears to not send a translation sometimes, but with patience, it does send the correct codes for every key. It's very sporadic. If I push the `F` key multiple times, it might not be detected, but when I push `F` and `G` in quick succession, both scancodes will be received. It seems like the keyboard is just very buggy when using scancode set 1.

I think the end solution is to just use scancode set 2 and replace my translation tables.

[bewing]

I was recently reading a very old thread where someone named Brendan said something like "many modern keyboards that I've tested only support scanset 2". If I try real hard, I might be able to find that thread. Or perhaps Brendan accidentally forgot to mention that fact in his first post.

[earlz]

Heh that'd be helpful. Also, while I'm here does anyone know of a piece of C code I can use for the scancode set 2 ascii mapping? I originally got my scancode set 1 mapping from http://www.osdever.net/bkerndev/index.php I can't find anything for scancode set 2 though. (Yes, I know I could write it myself, but I'm lazy )

[Brendan]

Hi,

If the same key works sometimes and doesn't work other times, then it's very unlikely that the problem is caused by scan code sets or translation. In this case, given that key repeat works, it's unlikely to be a problem with serial communications (baud rate, parity, etc). That doesn't leave many other causes.

Anyway, from my testing it appears to not send a translation sometimes, but with patience, it does send the correct codes for every key. It's very sporadic. If I push the `F` key multiple times, it might not be detected, but when I push `F` and `G` in quick succession, both scancodes will be received. It seems like the keyboard is just very buggy when using scancode set 1.

In this case, it's very unlikely that the problem is caused by scan code sets or translation. Maybe there's a noisy line or bad connection or something, maybe you're getting lots of parity errors or something, and maybe there's flow control issues (e.g. "buffer full" causing lost data because you're missing IRQs and/or not reading bytes from the controller fast enough).

I'd recommend cutting out as much code as possible (e.g. display raw hex bytes received by the keyboard controller), and also displaying any status/error flags that the controller has.

I was recently reading a very old thread where someone named Brendan said something like "many modern keyboards that I've tested only support scanset 2". If I try real hard, I might be able to find that thread. Or perhaps Brendan accidentally forgot to mention that fact in his first post.

I'm guessing that was about 10 years ago!


Cheers,

Brendan