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