lkml.org 
[lkml]   [1999]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: keyboard scancodes
On Wed, Dec 15, 1999 at 05:29:56AM +0100, Andries.Brouwer@cwi.nl wrote:

> : Ok, here goes the Set2->Set1 (and also AT->XT) table:
>
> : AT XT AT XT AT XT AT XT AT XT
> : 00 ff 20 67 40 6b 60 55 80 ??
> : 01 43 21 2e 41 33 61 56 81 ??
> : 02 41 22 2d 42 25 62 77 82 ??
> : 03 3f 23 20 43 17 63 78 83 41
> : 04 3d 24 12 44 18 64 79 84 37
> ...
>
> Good! However, I find that 84 is translated as 54.

Yes, possible.

> # * Your view of Set1 must be very confused, because it's a Set1
> # translated by the Set2->Set1 translation by the i8042, which must
> # be a mess.
>
> Very useful in fact. That way I was able to verify almost all of the table
> you quoted from Gary J Konzak.

A way how to verify the table completely would be to attach a mouse
to the keyboard port, set in it echo mode (send 0xee), then send bytes,
and see what comes, the mouse echoes back everything except 0xec -
echo cancel.

I think you'll find different results for different i8042's with this,
and that's one of the reasons I speak about the warped glass ...

Because then you have to care not only about keyboard quirks, but also
about i8042's quirks, and the result if you combine them ...

> # * Ahh, finally I see what you call kscancodes - my scancodes.h table
> # only deals with kscancodes, because that's the truth, it doesn't
> # make sense to look at the codes through the warped glass the i8042
> # provides.
>
> How is that glass warped? It is just a 1-1 correspondence, so before
> or after the map doesnt really make any difference. Another table.
> (And since most machines in the world use this translated Set 2 default,
> doing anything else only has the disadvantage that it won't work on
> some keyboards. In particular I wonder how faithful USB keyboards
> will emulate this old nonsense.)

It's a 1-1 correspondence for keys that generate scancodes < 127 in
Set2. However, this isn't the case for all keyboards - for example
the Focus9k and quite a bunch of other keyboards generate scancodes
> 128, and although the table isn't a problem, because it doesn't
change most of the keys above 127, adding the eighth bit for release
IS a problem - you get the same byte for both a press and a release
of a key, and although this can be worked around it's far from nice.

Because all keyboards use Set2 by default, all of them will also work
with the i8042 translation switched off - they don't know about it.
About whether all i8042's support switching the translation off -
I can't say for sure, but neither I nor anyone else was able to find
one that wouldn't be able to do that.

USB keyboards don't emulate the XT nonsense at all. It's the computers
BIOS that emulates this in software when you have an USB keyboard
attached, and does that through the SMM mode. And yes, it emulates
XT (translated set2) only. However that isn't a problem, since we
already have a native USB keyboard driver in the kernel, and the USB
controller XT keyboard emulation support is switched off immediately
upon loading the USB controller driver.

> P.S. Is it a 1-1 correspondence? Essentially, yes.
> The conversion table is a permutation on 01-7f.
> Remain 3 entries, one of which I disagree about with you, see above.
> The duplication of 41 at 02 and 83 causes problems for the keyboards
> that disregard the highest bit.

For some reason, most of the AT keyboards I have here generate 0x83 for
F7. Don't know why - the documented value is 0x02. But it's translated
correctly by the i8042.

> That is why the values of Set 3 for the keys 1 and 2 are anomalous.

Oops? They are not. Only one keyboard (the BTC one) has problems with
this, all others I have work fine.

> P.S.2 All this is only of historical interest. I am mainly interested
> in the question whether there are reasons not to use the USB keycodes
> as our 16-bit keycode standard.

Well, it would make things easier, the only problem is that the USB
HUT (Hid Usages Table) doesn't cover all the keys axisting on many
keyboards. We'd have to extend it to be useful ...

--
Vojtech Pavlik
SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.030 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site