On Sun, 30 Jan 2000, Michael Neuffer wrote:
>
> The only test that so far had any impact was the suggestion to
> disable the toshiba workaround. With the workaround enabled I get the
> "Timeout - AT keyboard not present ?" warning after starting gpm.
> If it is disabled, I do not hit this code path.
[ Tee-dee-tee-dee-tee-dee theme from "The Twilight Zone" ]
Basically, the mouse open routine does:
kbd_write_command_w(KBD_CCMD_MOUSE_ENABLE); /* Enable the
auxiliary port on
controller. */
aux_write_ack(AUX_ENABLE_DEV); /* Enable aux device */
kbd_write_cmd(AUX_INTS_ON); /* Enable controller ints */
send_data(KBD_CMD_ENABLE); /* try to workaround toshiba4030cdt problem */
and nothing more. The "Timeout" message comes from the final
"send_data()", which seems to imply nothing more than the fact that the
keyboard has already locked up by that time.
Now why any other driver _could_ make a difference here is very very
unclear. It might be a subtle timing issue, and nothing more. Or it migth
be something truly subtle indeed.
The fact that the keyboard does come back when the mouse is closed again
certainly implies that whatever the interaction is, it's not some other
driver (ie USB or PCMCIA) just stomping on the keyboard state by mistake.
It really is internal to the mouse/keyboard driver, and some other driver
just makes it show up.
More suggestions, if you have the time and the energy:
- try to use the "kbd-reset" kernel command line at bootup, see if that
makes any difference (it does a full keyboard init sequence at bootup,
and it has been known to matter on some machines).
- disable the keyboard before changing the controller mode in open_aux(),
and re-order the operations, ie make the init sequence look like this:
kbd_write_command_w(KBD_CCMD_MOUSE_ENABLE); /* Enable mouse controller */
send_data(KBD_CMD_DISABLE); /* Disable keyboard during mode set */
kbd_write_cmd(AUX_INTS_ON); /* Enable controller ints for both keyboard and mouse */
send_data(KBD_CMD_ENABLE); /* Enable keyboard again */
aux_write_ack(AUX_ENABLE_DEV); /* Enable the mouse itself */
which actually makes a lot more sense than the current one (makes the
mouse and keyboard controller and device "enabledness" be more regular:
both controllers are enabled during the mode set, but both devices are
disabled until after the mode-set is complete.
The keyboard controller documentation actually seems to imply that the
keyboard should be disabled during the mode set, so the above change in
setup may actually fix a real bug. Whether it's the bug that causes
problems, who knows?
Linus
-
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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:26 EST