Andries.Brouwer@cwi.nl wrote:
>
> > 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.
> 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.
> 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).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:50 EST