[gpm]Bug with IMPS/2 w/ Microsoft Intellimouse 1.3A on Linux

[Peter Berg Larsen]

On Sun, 16 Jun 2002, Pozsar Balazs wrote:

> > So any mouseinitialization where a respond is expected/needed should first
> > turn off datastreaming and flush the fd. Then begin to communicating with
> > the mouse. When ended turn on the datastreaming again.
> 
> I all figured out this, so that's exactly how the patch works :)

hmmm, I don't see any disable streaming at all :)


> > A) datamotion packets can legally take the value of 0.
> 
> I was thinking about this too. I do not know why, but the patch worked in
> every time: I couldn't make the init with moving the mouse around or
> pressing the buttons or scrolling the wheel (but I do tried.).
> 
> I thought that we should wait for an 0xAA first, then for a 0x00, and that
> should be enough, but I didn't have time for testing this.

What is done in synaptics.c is to stop the streaming and then a loop call
select and read any pending byte, until the que was empty, and check
afterwards that the last two read bytes is AA and 00. 



> > B) moving the mouse while initializing can cause the same problem.
> Well, as I said above I tested above I tested it on three mice, and I
> couldn't make the init fail. Can you? :)

Yes on the synaptics touhpad I could without the disable streaming.
However I don't believe condition B can happen, as the aux sepecification
says that the client should stop sending data if the host sends, so as I
said; your patch solves the problem most of the time.

But... as I also said it is a problem every nontrivial mouse
initialization is having, so why not make a general file with ps2 
functions such as reset, flush, enable, disable streaming etc?


Peter
--
E-Mail:       pebl@math.ku.dk 
Real name:    Peter Berg Larsen 
Where:        Department of Computer Science, Copenhagen Uni., Denmark