A colleague reported that the keyboard of his brandnew laptop
is dead under 2.6 while 2.4 works.
Now I once wrote
In order to avoid interference between scancode sequences
or mouse packets and the reponses given to commands,
the keyboard or mouse should always be disabled before
giving a command that requires a response, and probably
enabled afterwards. Some keyboards or mice do the disable
automatically in this situation, but still require an
explicit enable afterwards.
This is what happens on this laptop. The routine atkbd_probe()
probes for a keyboard, and after detecting it, enables it.
But immediately afterwards the routine atkbd_set_3() reads
the current scancode set and sets the desired set, and as a
side effect of these commands, the keyboard gets disabled again.
Thus, the keyboard enable must be moved after all command sending
has been done.
Now that I patch this area anyway: we are almost always in
scancode set 2 but send the ATKBD_CMD_SETALL_MB command
that only works in scancode set 3. At best this is useless.
At worst it confuses the keyboard. So, I put this command
in a separate routine and call that only when we really
are in scancode set 3.