Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 Aug 95 10:12:46 MDT
From:      terry@cs.weber.edu (Terry Lambert)
To:        freebsd-current@FreeBSD.org
Subject:   Re: Syscons and IBM ThinkPads
Message-ID:  <9508171612.AA12623@cs.weber.edu>
In-Reply-To: <199508170452.GAA08320@uriah.heep.sax.de> from "J Wunsch" at Aug 17, 95 06:52:28 am

next in thread | previous in thread | raw e-mail | index | archive | help
> So, if this information proves correct, MCA Type 2 controllers cannot
> turn the keyboard into ancient PC scan mode at all.  Pcvt continues to
> work (with PCVT_SCANSET=2) since it's able to work with set 1 or set 2
> scan codes (and ideally should be made working with set 3, too, since
> this set is way more rationale).

Since we're in a quoting mood:

''The PS/2 offers yet a third alternative.  Scan code set 3 generates
  a single byte code for any key pressed.  No key is affected by any
  shift state.  Since scan code set 3 is not supported on other AT+
  systems, the only useful purpose I can fathom is testing the keyboard
  during manufacturing.''

> Hmm.  If this were true, you couldn't run XFree86 at all.  XFree86
> still relies on set 1 keycodes, and all pcvt is doing here is setting
> the translate bit in the command byte.  Neither of our console drivers
> is interpreting the scan codes while X is running.

Well, it's entirely possible to cook the scan code 2's into scan code
1's for the benefit of X.  Really, you want to cook everything into
single code key down, single code key up (up == down | 0x80) and then
cook back from there.  This may be higher overhead, but then again,
keyboard input is hardly taxing on system resources.

This is difficult from scan code set 2, but table 8-5 indicates that
the additional "trick" functions for the edit key island between the
keypad and the keyboard proper rely on state toggle by having *another*
down sequence in an attempt to "fool" the motherboard controller.  I
have a hard time buying the example in note 1, however, since one
would expect the fake events to be key up/down rather than down/up.

In addition, it looks as if the Down/On example for the Home key in
the edit key island, shown as:

Shift	NumLock	Make code		Break code
Down	On	E0,6C			E0,F0,6C

Should really be some combination including 77 and 45.

Calculating the correct state table based on the additional codes is
basically the problem that causes people to use scan table 1 in the
first place, when possible.

It's unclear from the text whether one can rely on scan code set 3
existing for every instance where scan code set 1 is not supported.
The text implies a distinction in these cases by using the terms
"PS/2" and "MCA" seperately, implying a distinction is being drawn.

If a keyboard exists which *only* supports scan code set 2 and neither
1 nor 3, then there are some issues of modifier behaviour setting in
X which can not be expected to work in all cases.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9508171612.AA12623>