[lkml]   [2003]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: handling an oddball PS/2 keyboard (w/ patch)
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

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


--- 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)
@@ -230,11 +232,19 @@
goto out;
- atkbd->emul = 1;
- goto out;
+ if (atkbd->set != 3) {
+ atkbd->emul = 1;
+ goto out;
+ } else {
+ break;
+ }
- atkbd->emul = 2;
- goto out;
+ if (atkbd->set != 3) {
+ atkbd->emul = 2;
+ goto out;
+ } else {
+ break;
+ }
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) {
 \ /
  Last update: 2005-03-22 13:59    [W:0.056 / U:1.344 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site