]> git.hungrycats.org Git - linux/commit
[PATCH] another keyboard problem solved
authorAndries E. Brouwer <andries.brouwer@cwi.nl>
Wed, 10 Sep 2003 09:46:16 +0000 (02:46 -0700)
committerLinus Torvalds <torvalds@home.osdl.org>
Wed, 10 Sep 2003 09:46:16 +0000 (02:46 -0700)
commit907e4b7b5388fb1b056cc7b3e6878edc039ce27e
tree21057f19e88fac85a202fabd6228a2c87d012468
parent71d1c9ff9f56c175c3e10a956d399862c55f2c37
[PATCH] another keyboard problem solved

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.

(http://www.win.tue.nl/~aeb/linux/kbd/scancodes-9.html)

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.
drivers/input/keyboard/atkbd.c