This fixed the mouse for me, but not the keyboard.
Go figure.
I haven't attempted adding in the post-boot keyboard
reset yet. I'll let you know if that at least forces
my keyboard into the land of the living.
I've sent a ton of info already. Please let me know
if you need anything I've left out up 'til now.
Thanks,
Miles
Linus Torvalds wrote:
>
> 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