handling an oddball PS/2 keyboard

handling an oddball PS/2 keyboard

[David Monro]

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...)

Re: handling an oddball PS/2 keyboard

[Andries Brouwer]

On Thu, Dec 25, 2003 at 02:49:40AM +0000, David Monro wrote:

> 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.

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?

> 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).

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

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

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

Re: handling an oddball PS/2 keyboard

[John Bradford]

> I suppose Vojtech will have no objections to using this ID
> to skip the tests for e0 and e1 as protocol (escape) scancodes.

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.

Re: handling an oddball PS/2 keyboard

[David Monro]

Andries Brouwer wrote:
> On Thu, Dec 25, 2003 at 02:49:40AM +0000, David Monro wrote:
> 
> 
>>I have a slightly odd PS/2 keyboard which I'm not quite sure of the best 
[..]
> 
> 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?

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.

> 
>>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 
[..]
> 
> 
> Yours is the second report I see for ID 0xab85.
[..]
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

Re: handling an oddball PS/2 keyboard

[David Monro]

John Bradford wrote:
>>I suppose Vojtech will have no objections to using this ID
>>to skip the tests for e0 and e1 as protocol (escape) scancodes.
> 
> 
> 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 :-) ).

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

Cheers,

	David

> 
> John.

Re: handling an oddball PS/2 keyboard

[John Bradford]

Quote from David Monro <davidm@amberdata.demon.co.uk>:
> John Bradford wrote:
> >>I suppose Vojtech will have no objections to using this ID
> >>to skip the tests for e0 and e1 as protocol (escape) scancodes.
> > 
> > 
> > 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 :-) ).
> 
> I will definitely explore this possibility. Whats the ID of your 
> keyboard? (and what is it?)

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.

Re: handling an oddball PS/2 keyboard (w/ patch)

[David Monro]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

David Monro wrote:
> John Bradford wrote:
> 
[..]
>> 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
[..]

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

[-- Attachment #2: atkbd.c.diff --]
[-- Type: text/plain, Size: 1060 bytes --]

--- atkbd.c.ORIG	Thu Dec 25 02:19:28 2003
+++ atkbd.c	Fri Dec 26 01:40:47 2003
@@ -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) {

Re: handling an oddball PS/2 keyboard (w/ patch)

[Vojtech Pavlik]

On Fri, Dec 26, 2003 at 02:04:27AM +0000, David Monro wrote:
> David Monro wrote:
> >John Bradford wrote:
> >
> [..]
> >>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
> [..]
> 
> 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),

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.

> and for another it still does e0/e1 translation for set3 - which imho is 
> wrong.

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.

> 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.

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

> 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 :)

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

> 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 :)

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

Re: handling an oddball PS/2 keyboard (w/ patch)

[Andries Brouwer]

On Fri, Dec 26, 2003 at 11:22:10AM +0100, Vojtech Pavlik wrote:

> This is intentional. Set 3 was never meant to be translated.

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

Re: handling an oddball PS/2 keyboard (w/ patch)

[Vojtech Pavlik]

On Sat, Dec 27, 2003 at 12:58:43AM +0100, Andries Brouwer wrote:

> On Fri, Dec 26, 2003 at 11:22:10AM +0100, Vojtech Pavlik wrote:
> 
> > This is intentional. Set 3 was never meant to be translated.
> 
> 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.

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