FYI PS/2 Mouse problems -- userland issue
Quoted 3 lines
Armed with docs I was able to see just why our code is completely wrong for handling things like the ps/2 mouse being removed at runtime.
Yes, or being added, to be more precise. But it will not be easy to do it right. So many different ps2-like types of mouse. There are heuristics, like the AA 00 that I gave last week or so. (But not every ps2-mouse emits this sequence.)
And one can keep track of the timing. But the fact that the length of a packet is unknown (3, 4, 5, 8 bytes), and that in some modes and relative positions arbitrary data is legal, makes it more or less impossible to write code that is provably correct.
Also state machines have difficulties. Many types of mouse react to special sequences of ordinary commands, and enter a non-ps2 mode.
As we already remarked in the previous round,
this is no kernel business.
Andries
[departing now - probably away from email for a while]
Quoted 8 lines · On Tue, 21 Aug 2001 [email protected] wrote:
Quoted 3 lines
Armed with docs I was able to see just why our code is completely wrong for handling things like the ps/2 mouse being removed at runtime.
Yes, or being added, to be more precise. But it will not be easy to do it right. So many different ps2-like types of mouse. There are heuristics, like the AA 00 that I gave last week or so. (But not every ps2-mouse emits this sequence.)
That's what reset probes are for... =) At least in the case of the mouse, this really isn't the kernel's business. But for the keyboard, it is.
Quoted 1 line
Also state machines have difficulties. Many types of mouse react
The state machine I'm talking about is for the general keyboard controller poking code which currently is well sprinkled with udelay()s. I really don't want my dual 1.2GHz CPUs waiting on a keyboard controller.
-ben
Quoted 9 lines · [email protected] wrote:
Quoted 4 lines
Armed with docs I was able to see just why our code is completely wrong for handling things like the ps/2 mouse being removed at runtime.
Yes, or being added, to be more precise. But it will not be easy to do it right. So many different ps2-like types of mouse. There are heuristics, like the AA 00 that I gave last week or so. (But not every ps2-mouse emits this sequence.)
Not every mouse controller lets this sequence thru ? (e.g. laptops with simultaneous stick +ps2 mouse)
A mouse not emitting this sequence would be broken. However you could easily recover by polling the mouse status every second. A newly-plugged mouse will have characteristic bit pattern.
Quoted 4 lines
And one can keep track of the timing. But the fact that the length of a packet is unknown (3, 4, 5, 8 bytes), and that in some modes and relative positions arbitrary data is legal, makes it more or less impossible to write code that is provably correct.
See above for a perfect solution.
Quoted 2 lines
Also state machines have difficulties. Many types of mouse react to special sequences of ordinary commands, and enter a non-ps2 mode.
See http://home.t-online.de/home/gunther.mayer/gm_psauxprint-0.01.c
for a _dirty_ hack collecting info from various sources. This is the first linux tool to implement the PS2-PNP protocol (for identifying MS mice).