xmodmap 1.0.7: "left shift" + "right shift" + "comma" keys

[Glynn Clements]

YuGiOhJCJ Mailing-List wrote:

> What is a bit strange is that my keyboard can handle the "left
> shift" + "right shift" + "exclam" but is not able to handle the
> "left shift" + "right shift" + "comma" that seems to be similar
> (same number of keys pushed at the same time).

I did a quick test. This is with a UK keyboard; the bottom row is:

	[Shift] \ Z X C V B N M , . / [Shift]


With the left and right Shift keys held down, the keys

	\ B N /

generate an event, while the keys

	Z X C V M , .

don't.

The reasons relate to the concept of a keyboard matrix, and the
details to the exact layout of the matrix.

A keyboard doesn't have each switch connected to a separate input pin
on the controller chip. Instead, the switches are layed out in a grid,
with an ouput line from the controller connected to each "row", and an
input connected to each "column".

[Note that the "rows" and "columns" of the grid don't have to
correspond to the physical layout of the circuit board and the
positions of the keys, and usually don't. They're only rows and
columns in terms of the schematic (circuit diagram).]

The controller energises one output pin at a time, and checks which
inputs are energised. The process is known as "scanning", hence the
term "scan code" for the low-level fixed codes associated with each
key.

With one key pressed, one row is connected to one column. When the
output for the row is energised, the input for the column will also be
energised. Suppose you press the key at A1:

            1       2

            o       o
            |       |
    A  o----+------- --
            |       |
            |       |
    B  o---- ------- --
            |       |

When row A is energised, the switch at A1 causes column 1 to be
energised.. When row B is energised, none of the columns are
energised. The controler notes this and deduces that the switch at A1
is closed (i.e. the corresponding key is pressed) So far, so good.

If multiple keys are pressed, and all are in the same row, again
there's no problem. When that row is energised, the inputs for all of
the keys will be energised. Consider the case where A1 and A2 are
pressed:

            1       2

            o       o
            |       |
    A  o----+-------+--
            |       |
            |       |
    B  o---- ------- --
            |       |

When row A is energised, the switches at A1 and A2 cause columns 1 and
2 to be energised. The controller deduces that both A1 and A2 are
closed.

If multiple keys are pressed, and all are in different rows and
different columns, there's still no problem. Consider the case where
A1 and B2 are pressed:

            1       2

            o       o
            |       |
    A  o----+------- --
            |       |
            |       |
    B  o---- -------+--
            |       |

When row A is energised, the switch at A1 causes column 1 to be
energised. When row B is energised, the switch at B2 causes column 2
to be energised. The controller deduces that both A1 and B2 are
closed.

The problem arises when you have at least three keys pressed, two of
which are in one row, and the third is in another row but the same
column as one of the first two:

Suppose you press the three keys corresponding to positions A1, A2 and
B2 (but not the one for B1):

            1       2

            o       o
            |       |
    A  o----+-------+--
            |       |
            |       |
    B  o---- -------+-
            |       |


When row A is energised, the switches at A1 and A2 cause columns 1
and 2 to be energised.

When row B is energised, the switch at B2 causes column 2 to be
energised.

But the switch at A2 also causes row A to be energised, and the switch
at A1 causes column 1 to be energised. So the controller sees both
columns 1 and 2 energised whenever row A or row B are energised. So it
looks to the controller as if all four switches are closed, when B1 is
in fact open, resulting in a "phantom" key press.

If you compare the last two cases, the difference is that the latter
has A2 closed while the former doesn't. With A1 and B2 already closed,
closing A2 causes both A2 and B1 to appear to close simultaneously.

The controller recognises that this situation has occurred. It handles
it by simply ignoring both of the new key presses, as it cannot
determine which one is real and which one is a "phantom".

The actual matrix layout used by most keyboards is chosen to avoid
problems for the most important cases.

Note that pressing both Shift keys simultaneously *isn't* the sort of
case which the designers would put effort into avoiding (likewise for
both Control keys), as this isn't how those keys are normally used. 
You would try to ensure that Control, Shift, and Alt in combination
with any other key would work, as modifiers are normally used in
"chords".

More expensive keyboards (e.g. some "gaming" keyboards) avoid this
problem by adding diodes in series with (some of) the switches, so
that current can only flow from the rows to the columns, and not
vice-versa. But that adds to the cost, and most modern keybards are
nothing if not cheap.

-- 
Glynn Clements <glynn at gclements.plus.com>