handling an oddball PS/2 keyboard

Hi,

I have a slightly odd PS/2 keyboard which I'm not quite sure of the best way to handle. Its an NCD N-97, which shipped with some NCD X terminals and also with some Mips workstations IIRC. Most of the keys produce the normal scancodes, and most which don't can be fixed using setkeycodes. However there are 2 keys which can't be made to work, which are F9 and F10. The problem is that these produce raw scancodes 0x60 and 0x61, which means the _release_ codes (setting the top bit) are 0xe0 and 0xe1. Unfortunately on a normal PS/2 keyboard these are special prefixes, and so pressing these keys usually ends up getting the keyboard driver into a very confused state.

What would be the cleanest way of handling this? My quick and dirty plan is to add a parameter to the atkbd module which just disables the special handling of e0 and e1 (which from a cursory glance seems to be pretty easy). However, I know that the NCD X terminals used to be able to autodetect this keyboard. I'm guessing that they did this using the ATKBD_CMD_GETID command, which on this keyboard returns 0xab85 (and the comments in atkbd.c suggest that 0xab83 is normal). So the _really_ neat way of handling this would be to match that ID and turn off the e0/e1 processing then (and it would also allow me to map the keys correctly out-of-the box...).

So.. could I get a bunch of people to have a look in /proc/bus/input/devices, and see what the 'Version' field for their keyboard is? If it turns out that 0xab85 turns up on normal keyboards then obviously I'll have to abandon the 2nd approach (or find another way to ID it).

What chance would either of these approaches have of getting merged?

Cheers,

David

(please CC to me, I'm not currently subscribed...)

Interesting. I rearranged my scancode data page a bit and added your info - see http://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html
Are your scancodes identical to those reported by Benjamin Carter?

The overwhelming majority of all keyboards give 0xab83, translated to 0xab41, incorrectly back translated by the 2.6 kernel to 0xab02.

Yours is the second report I see for ID 0xab85.
I have no information on the details of the other keyboard.
I suppose Vojtech will have no objections to using this ID
to skip the tests for e0 and e1 as protocol (escape) scancodes. Either everybody is happy, or we learn a bit more about unusual keyboards.

Andries

There might be no need for such a workaround - a lot of PS/2 devices which were not intended for PCs work fine in set 3, particularly if the device they were intended to work with uses set 3 natively, where this conflict with protocol scancodes problem doesn't exist. If the keyboard works in set 3, add 0xab85 to the list of keyboards to force set 3 for, (and maybe also add the ID for my keyboard while we're at it :-) ).

John.

[..]

Almost precisely! The only differences I can see are probably a result of his being a japanese one; the physical layout is a little different and I have PF1-PF4 above the numeric keypad rather than the japanese compose keys. I'll send you a more detailed description for your page.

[..]

[..]
Hmm. I've seen those extended 122 key IBM keyboards, although I _think_ most of the ones I've seen have been the APL variant. I may know someone who has one, so I'll see if I can get hold of it to test.

Cheers,

David

I will definitely explore this possibility. Whats the ID of your keyboard? (and what is it?)

Cheers,

David

Quote from David Monro <[email protected]>:

It's an IBM Japanese keyboard which emulates a U.S. one. Andries has quite a bit of information about it on his page, but the interesting thing is that it doesn't do any emulation in set 3, only in the default set 2. The ID is ab90. There may be ab90 ID keyboards out there which are not set 3 compatible, I don't know. Mine is certainly not fully usable in set 2, though, as the language keys produce the same codes as the space bar.

John.

[..]

[..]

Ok I've turned my brain on and looked at the difference between set2 and set3... and its trivial! The NCD N-97 returns set3 keycodes even when its told to be in set2. Thanks very much for making me look at that!

So my first thought was to just pass the atkbd_set=3 option to the kernel. Which doesn't work - I still get set2. Looking at atkbd.c it really doesn't handle _translated_ set3 at all - for one thing atkbd_set_3() forces set2 if we have a translating i8042 (ie normality), and for another it still does e0/e1 translation for set3 - which imho is wrong.

Both of these can be avoided by passing the i8042_direct option to the
i8042 module however, since that puts the i8042 into non-translating mode. However this can have undesirable side effects - for example my bios appears to re-enable translating mode if I suspend/resume.

So. Short term solution is just to pass atkbd_set=3 and i8042_direct=1 to the kernel, and live without suspend/resume (and that should work for John as well).

Longer term: fix atkbd.c to handle translated set3 correctly, and then just use atkbd_set=3. Vojtech: I've included a patch which I think does this, and works for me; do you think it looks reasonable? I've just done a couple of quick hacks to make this work (basically assume anyone who sets atkbd_set= knows what they are doing, and don't special-case e0/e1 in set3) - but is that all there is to it? I've assumed that all other codes are still valid in set3. I also haven't done it very prettily :)

Even the above won't fix things for anyone who has a keyboard which a) needs set3 handling b) generates codes above 0x7F c) has a broken i8042 translation implementation which mangles the codes above 0x7F and d) has a problem using the i8042 in raw mode because of suspend/resume... in which case, I think that will have to be fixed by getting the i8042 code to reset raw mode on resume.. if thats even possible. Fortunately I think this should be a very rare case :)

Cheers,

David

@@ -196,8 +196,10 @@
 	if (atkbd->translated) do {
 
 		if (atkbd->emul != 1) {
-			if (code == ATKBD_RET_EMUL0 || code == ATKBD_RET_EMUL1)
-				break;
+			if (atkbd->set != 3) {
+				if (code == ATKBD_RET_EMUL0 || code == ATKBD_RET_EMUL1)
+					break;
+			}
 			if (code == ATKBD_RET_BAT) {
 				if (!atkbd->bat_xl)
 					break;

@@ -230,11 +232,19 @@
 			serio_rescan(atkbd->serio);
 			goto out;
 		case ATKBD_RET_EMUL0:
-			atkbd->emul = 1;
-			goto out;
+			if (atkbd->set != 3) {
+				atkbd->emul = 1;
+				goto out;
+			} else {
+				break;
+			}
 		case ATKBD_RET_EMUL1:
-			atkbd->emul = 2;
-			goto out;
+			if (atkbd->set != 3) {
+				atkbd->emul = 2;
+				goto out;
+			} else {
+				break;
+			}
 		case ATKBD_RET_RELEASE:
 			atkbd->release = 1;
 			goto out;

@@ -482,7 +492,7 @@
  * IBM RapidAccess / IBM EzButton / Chicony KBP-8993 keyboards.
  */
 
-	if (atkbd->translated)
+	if ((atkbd->translated) && (atkbd_set == 2))
 		return 2;
 
 	if (atkbd->id == 0xaca1) {

This is intentional. Set3 was never meant to be translated. If you want to use it, just pass i8042_direct=1 to the kernel (or the i8042 module). Then you get untranslated Set3. If you're using a Set3 keyboard with a mainboard that cannot handle Untranslation and Set3 correctly, well, then choose a different keyboard or mainboard, they're not compatible.

Indeed this is wrong, but needed for many keyboards, which incorrectly use the e0 prefix even in set3. However, this shoul pose no problem for keyboards which use proper set3.

This can be fixed by restoring the i8042 chip configuration upon resume (fix planned, I think Dmitry has one already).

I'm not very keen on going this way, see above.

Yes, there are and will be unsupported configurations. d) will be fixed by setting i8042 to bootup values when suspending and to kernel values when resuming. a) b) and c) will be fixed by turning off translation in those cases and relying on it working because of d).

Vojtech Pavlik
SuSE Labs, SuSE CR

In fact it is just the opposite. Set 3 was designed to be translated. Look at the translated codes:
Q (10), W (11), E (12), R (13), T (14), Y (15), U (16), I (17), O (18), P (19). Completely regular.
Now look at the untranslated codes:
Q (15), W (1d), E (24), R (2d), T (2c), Y (35), U (3c), I (43), O (44), P (4d). Messy.

Andries

Not at all. If you draw the whole keyboard, you can see the underlying matrix of the Set3 codes.

And most importantly, there are more than a few set3 keyboards which have scancodes which cannot be translated safely (either > 0x80 or codes like 0x7e).

Vojtech Pavlik
SuSE Labs, SuSE CR